When using QEMU for Xen PV guest, QEMU abort with:
xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type generic-pc-machine
This is because the machine 'xenpv' also use accel=xen. Moving the code
to xen_hvm_init() fix the issue.
This fix 021746c131.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Since f615f39 (exec: remove ram_addr argument from
qemu_ram_block_from_host), migration under Xen is likely to fail, with a
SEGV of QEMU. But the commit only reveal a bug with the calculation of
the offset value in qemu_ram_block_from_host().
This patch calculates the offset from the ram_addr as
qemu_ram_addr_from_host() will later calculate the ram_addr from the
offset.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
After commit e5e7855 (blockdev: Separate BB name management), starting a
guest with PVHVM support result in this assert:
qemu-system-i386: block/block-backend.c:173: blk_delete: Assertion `!blk->name' failed.
A backtrace show that a caller is pci_piix3_xen_ide_unplug().
This patch fix it.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-id: 1460382666-29885-1-git-send-email-anthony.perard@citrix.com
Signed-off-by: John Snow <jsnow@redhat.com>
This fix migration from the same QEMU version and from previous QEMU
version.
>From the global state section, we don't need runstate with Xen. Right now,
the way the Xen toolstack knows when QEMU is ready is when QEMU reach
"running" runstate.
The configuration section and the section footers are not going to be
present in previous version of QEMU with xenfv machine, so we skip them.
The Xen toolstack libxenlight does not specify a particular version of the
'pc' machine, so migration from older version of QEMU used by Xen to newer
one would break due to missing "configuration" section and section footers.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
When doing migration via the QMP command xen_save_devices_state, the
current runstate is not store into the global state section. Also the
current runstate is not the one we want on the receiver side.
During migration, the Xen toolstack paused QEMU before save the devices
state. Also, the toolstack expect QEMU to autostart when the migration is
finished.
So this patch store "running" as it's current runstate.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
QEMU does not need and should not allocate memory for the ROM of a
passthrough PCI device. So this patch initialize the particular region
like any other PCI BAR of a passthrough device.
When a guest will access the ROM, Xen will take care of the IO, QEMU
will not be involved in it.
Xen set a limit of memory available for each guest, allocating memory
for a ROM can hit this limit.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
The qxl driver expect NULL for QXLRam.memory_configs, but this is never
initialized.
If memory is set to 0xc2c2.., it leads to a spice-critical error when
trying to start qxl.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
video ram. This case happens during migration.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Avi Kivity <avi@redhat.com>
This new helper/hook is used in the next patch to add an extra call in a single
place.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Avi Kivity <avi@redhat.com>
This function is to be used during live migration. Every write access to the
guest memory should call this funcion so the Xen tools knows which pages are
dirty.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This command is used during a migration of a guest under Xen. It calls
memory_global_dirty_log_start or memory_global_dirty_log_stop according to the
argument pass to the command.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
The Xen platform device will unplug any NICs if requested by the guest (PVonHVM)
including a NIC that would have been passthrough. This patch makes sure that a
passthrough device will not be unplug.
Reported-by: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
The xs.h header is now deprecated and produces a warning. This prevents the
configure script from enabling Xen with xen-unstable whom will become 4.2. As
this header is not anymore common to every version of Xen, we just remove it
from the early probe for Xen.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
The purpose is to have a more generic pci_for_each_device by passing an extra
argument to the function called on every device.
This patch will be used in a next patch.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Because xs.h will be remove in future release of Xen, this patch removes the
extra includes of this headers.
Also, it removes the extra includes of xenctrl.h and xen/io/xenbus.h as there
already are in xen_common.h.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In the context of PV-on-HVM under Xen, the emulated nics are supposed to be
unplug before the guest drivers are initialized, when the guest write to a
specific IO port.
Without this patch, the guest end up with two nics with the same MAC, the
emulated nic and the PV nic.
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
In the context of PV-on-HVM under Xen, the emulated nics are supposed to be
unplug before the guest drivers are initialized, when the guest write to a
specific IO port.
Without this patch, the guest end up with two nics with the same MAC, the
emulated nic and the PV nic.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Make clean does not clean the 'qom' directory, leaving *.o and *.d files. This
patch fixes this.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
This patch changes the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.
This help to have a succefull migration.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In cpu_physical_memory_rw, a change has been introduced and qemu_get_ram_ptr is
no longuer called with the ram addr we want to access, but only with the
section address. This patch fixes this. (All other call to qemu_get_ram_ptr are
already called with the right address.)
This patch fixes Xen guest.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Value check in PCI Express Base Specification rev 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Actually, pci_parse_devaddr checks if the dom/bus of the PCI address exist. But
this should be the jobs of a caller. In fact, the two callers of this function
will try to retrieve the PCIBus related to the devaddr and return an error if
they cannot.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
A recent patch set from Avi break the dirty bitmap support of Xen. But
this is because xen_sync_dirty_bitmap will return an error for an
unhandled memory range (a0000 - bffff). However this is not a fatal
error, so we should just continue instead of aborting.
There is now an error printed when the Xen call failed.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Previously, the address space soft limit was set mcache_max_size. So,
before the mcache_max_size was reached by the mapcache, QEMU was killed
for overuse of the virtual address space.
This patch fix that by setting the soft limit the maximum than can have
QEMU. So the soft and hard limit are always set to RLIM_INFINITY if QEMU
is privileged.
In case QEMU is not run as root and the limit is too low, the maximum
mapcache size will be set the rlim_max - 80MB because observed that QEMU
use 75MB more than the maximum mapcache size after several empirical
tests.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
As a Xen guest can have more than 2GB of RAM on a 32bit host, we move
the conditions after than we now if we run one Xen or not.
[agraf] separate xen branch from ram_size check
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
A Xen guest memory is allocated by libxc. But this memory is not
allocated continuously, instead, it leaves the VGA IO memory space not
allocated, same for the MMIO space (at HVM_BELOW_4G_MMIO_START of size
HVM_BELOW_4G_MMIO_LENGTH).
So to reflect that, we do not register the physical memory for this two
holes. But we still keep only one RAMBlock for the all RAM as it is more
easier than have two separate blocks (1 above 4G). Also this prevent QEMU
from use the MMIO space for a ROM.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
In Xen case, memory can be bigger than the host memory. that mean a
32bits host (and QEMU) should be able to handle a RAM address of 64bits.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
As the variable pd and addr1 inside the function cpu_physical_memory_rw
are mean to handle a RAM address, they should be of the ram_addr_t type
instead of unsigned long.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Remove the call to xenstore_record_dm_state from xen_main_loop_prepare
that is HVM specific.
Add a new vm_change_state_handler shared between xen_pv and xen_hvm
machines to record the VM state to xenstore.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This patch introduces phys memory client for Xen.
Only sync dirty_bitmap and set_memory are actually implemented.
migration_log will stay empty for the moment.
Xen can only log one range for bit change, so only the range in the
first call will be synced.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This function will be used to support sync dirty bitmap.
This come with a check against every Xen release, and special
implementation for Xen version that doesn't have this specific call.
This function will not be usable with Xen 3.3 because the behavior is
different.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This tells to the xen management tool that the machine can begin run.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Introduce two functions qemu_shutdown_requested_get and
qemu_reset_requested_get to get the value of shutdown/reset_requested
without reset it.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
With MapCache, we can handle a 64b target, even with a 32b host/qemu.
So, we need to have target_phys_addr_t to 64bits.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
This function allows to unlock a ram_ptr give by qemu_get_ram_ptr. After
a call to qemu_put_ram_ptr, the pointer may be unmap from QEMU when
used with Xen.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
This patch introduces Xen specific call in piix_pci.
The specific part for Xen is in write_config, set_irq and get_pirq.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
This is because there is not synchronisation of the vcpu register
between Xen and QEMU, so vmport can't work properly.
This patch introduces no_vmport parameter to pc_basic_device_init.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Introduce the Xen FV (Fully Virtualized) machine to Qemu, some more Xen
specific call will be added in further patches.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This patch moves above_4g_mem_size and below_4g_mem_size calculation in
the caller of pc_memory_init (pc_init1). And the prototype of
pc_memory_init is changed because there is no need anymore to have
variable pointer and the ram_size parameter.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This patch updates the libxenctrl calls in Qemu to use the new interface,
otherwise Qemu wouldn't be able to build against new versions of the
library.
We check libxenctrl version in configure, from Xen 3.3.0 to Xen
unstable.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
xen_domainbuild and xen_machine_pv are built only for i386 targets.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
With this new field, we can specified which accelerator use to run the
machine, if the accelerator is not already specified by either a
configuration file or the command line options.
Currently, the only use will be made in the xenfv machine.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This option gives the ability to switch one "accelerator" like kvm, xen
or the default one tcg. We can specify more than one accelerator by
separate them by a colon. QEMU will try each one and use the first whose
works.
So,
./qemu -machine accel=xen:kvm:tcg
which would try Xen support first, then KVM and finally TCG if none of
the other works.
By default, QEMU will use TCG. But we can specify another default in the
global configuration file.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
In order to use log_start/log_stop with Xen as well in the vga code,
this two operations have been put in CPUPhysMemoryClient.
The two new functions cpu_physical_log_start,cpu_physical_log_stop are
used in hw/vga.c and replace the kvm_log_start/stop. With this, vga does
no longer depends on kvm header.
[ Jan: rebasing and style fixlets ]
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Anthony PERARD