When failing a migration / save due to the domain owning a PCI device
make sure that we tell the user what went wrong!
Signed-off-by: Mark Williamson <mark.williamson@cl.cam.ac.uk>
This can potentially cause a whole machine crash, which I think has
been seen in the wild. The case in the wild was caused by xendomains
auto-resuming domains on reboot, so it wasn't even operator error.
There's no sane way to migrate or suspend domains with PCI devs,
so I disallow it completely.
Signed-off-by: Mark Williamson <mark.williamson@cl.cam.ac.uk>
This patch adds a duplication definition check for devices.
It checks the following definitions.
- vbd : uname and device name
- vif : mac
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
By the time we test if addr is the upper word it has already been
aligned to the 8 byte pte size.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
Check the 'log_reload' on every iteration of the select() loop, not just when
select() returns EINTR. This is because the log reload signal may have
iterrupted a syscall other than select & thus without this change we
might miss the reload signal. The second change makes us process the
hypervisor logs on every iteration of the loop, not just upon timeouts.
This is because if a guest VM were consistently sending some log message
and < 1 second period, the select() would never hit the 1 second timeout
and thus never process the HV logs.
Thanks to Markus Armbruster for pointing out both these edge cases
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Following functions can be __init in Linux, however shouldn't
in Xen. __print_IO_APIC is called by keyhandler, while
setup_ioapic_dest is invoked in one platform hypercall.
Signed-off-by Kevin Tian <kevin.tian@intel.com>
against a late firing timer callback function (e.g. hpet_timer_fn) which
tries to access local APIC state.
Signed-off-by: Steven Hand <steven@xensource.com>
Properly handle MCE (connecting the exisiting, but so far unused
vendor specific handlers). HVM guests don't own CR4.MCE (and hence
can't suppress the exception) anymore, preventing silent machine
shutdown.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
are always stored/restored correctly despite the potential for an NMI
(and also MCE, with a subsequent patch) to kick in.
The idea is to always check values read from %ds and %es against
__HYPERVISOR_DS, and only store into the current frame (all normal
handlers) or the outer-most one (NMI and MCE) if the value read is
different. That way, any NMI or MCE occurring during frame setup will
store selectors not saved so far on behalf of the interrupted handler,
with that interrupted handler either having managed to read the guest
selector (in which case it can store it regardless of whether NMI/MCE
kicked in between the read and the store) or finding __HYPERVISOR_DS
already in the register, in which case it'll know not to store (as the
nested handler would have done the store).
For the restore portion this makes use of the fact that there's
exactly one such code sequence, and by moving the selector restore
part past all other restores (including all stack pointer adjustments)
the NMI/MCE handlers can safely detect whether any selector would have
been restored already (by range checking EIP) and move EIP back to the
beginning of the selector restore sequence without having to play with
the stack pointer itself or any other gpr.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
I'm suggesting this change to make another tiny step towards the
ability to run the tools e.g. out of the build tree (so that multiple
different Xen versions can co-exist without the requirement to
re-install the respective version with each boot).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
In order to at least have some minimal debuging capabilities when Xen
crashes really early, dump out registers and stack contents in a raw
form.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
In order to allow appending to the dom0 command line even with boot
loaders that only allow editing the kernel (i.e. Xen in our case)
command line, support a '--' separator option.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
More than doubles performance of page clearing on not too old
processors (SSE2 supported).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
pointers to const or arrays.
Only build-tested on ia64, and untested for powerpc (which, however,
is almost identical to ia64, except for an apparent bug in the original
version of __copy_field_{from,to}_guest in that the field offset was
multiplied by the field size).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Latch guest shared info format when hypercall page is being set up
rather than during an arbitrarily selected hypercall.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
Make sure command lines like
... vgaxyz vga=
... console=vga vga=
do not mistakenly ignore the vga= option due to finding 'vga' earlier
on the line.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
Normally by default, SIGUSR2 is not blocked, so the signal masks of
SIGUSR2 in all threads is unblocked.
When creating HVM guest, if we use the Qcow format image file, in the
main thread, Qcow uses SIGUSR2 to be notified of the completion of the
request after it issues an AIO request; in tools/ioemu/block.c:
bdrv_read_em(), in some point between bdrv_aio_read() and
qemu_aio_wait(), Dom0 may send a SIGUSR2 to Qemu immediately to
indicate the completion of an AIO request -- since at the moment
SIGUSR2 in main thread is blocked by qemu_aio_wait_start(), the signal
may be delivered to one non-main thread, causing the signal handler of
SIGUSR2 is invoked, then the main thread hangs in
qemu_aio_wait()->syswait()...
This patch blocks SIGUSR2 at the beginning of Qemu's main(), so it
ensures SIGUSR2 is blocked by default when a new thread is created,
then only the threads that use the signal unblock it.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
