summaryrefslogtreecommitdiff
path: root/xen-common.c
AgeCommit message (Collapse)AuthorFilesLines
2016-02-10xen: drop XenXC and associated interface wrappersIan Campbell1-2/+2
Now that 4.2 and earlier are no longer supported "xc_interface *" is always the right type for the xc interface handle. With this we can also simplify the handling of the xenforeignmemory compatibility wrapper by making xenforeignmemory_handle == xc_interface, instead of an xc_interface* and remove various uses of & and *h. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
2016-01-29xen: Clean up includesPeter Maydell1-0/+1
Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1453832250-766-14-git-send-email-peter.maydell@linaro.org
2016-01-26xen: Switch uses of xc_map_foreign_{pages,bulk} to use libxenforeignmemory API.Ian Campbell1-0/+6
In Xen 4.7 we are refactoring parts libxenctrl into a number of separate libraries which will provide backward and forward API and ABI compatiblity. One such library will be libxenforeignmemory which provides access to privileged foreign mappings and which will provide an interface equivalent to xc_map_foreign_{pages,bulk}. The new xenforeignmemory_map() function behaves like xc_map_foreign_pages() when the err argument is NULL and like xc_map_foreign_bulk() when err is non-NULL, which maps into the shim here onto checking err == NULL and calling the appropriate old function. Note that xenforeignmemory_map() takes the number of pages before the arrays themselves, in order to support potentially future use of variable-length-arrays in the prototype (in the future, when Xen's baseline toolchain requirements are new enough to ensure VLAs are supported). In preparation for adding support for libxenforeignmemory add support to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to switch to using the new API. These shims will disappear for versions of Xen which include libxenforeignmemory. Since libxenforeignmemory will have its own handle type but for <= 4.6 the functionality is provided by using a libxenctrl handle we introduce a new global xen_fmem alongside the existing xen_xc. In fact we make xen_fmem a pointer to the existing xen_xc, which then works correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc handle is a pointer). In the latter case xen_fmem is actually a double indirect pointer, but it all falls out in the wash. Unlike libxenctrl libxenforeignmemory has an explicit unmap function, rather than just specifying that munmap should be used, so the unmap paths are updated to use xenforeignmemory_unmap, which is a shim for munmap on these versions of xen. The mappings in xen-hvm.c do not appear to be unmapped (which makes sense for a qemu-dm process) In fb_disconnect this results in a change from simply mmap over the existing mapping (with an implicit munmap) to expliclty unmapping with xenforeignmemory_unmap and then mapping the required anonymous memory in the same hole. I don't think this is a problem since any other thread which was racily touching this region would already be running the risk of hitting the mapping halfway through the call. If this is thought to be a problem then we could consider adding an extra API to the libxenforeignmemory interface to replace a foreign mapping with anonymous shared memory, but I'd prefer not to. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
2015-08-03migration: Fix regression for xenfv and pc,accel=xen machine.Anthony PERARD1-0/+5
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>
2014-10-09accel: Pass MachineState object to accel init functionsEduardo Habkost1-1/+1
Most of the machine options and machine state information is in the MachineState object, not on the MachineClass. This will allow init functions to use the MachineState object directly instead of qemu_get_machine_opts() or the current_machine global. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-10-04accel: Rename 'init' method to 'init_machine'Eduardo Habkost1-1/+1
Today, all accelerator init functions affect some global state: * tcg_init() calls tcg_exec_init() and affects globals such as tcg_tcx, page size globals, and possibly others; * kvm_init() changes the kvm_state global, cpu_interrupt_handler, and possibly others; * xen_init() changes the xen_xc global, and registers a change state handler. With the new accelerator QOM classes, initialization may now be split in two steps: * instance_init() will do basic initialization that doesn't affect any global state and don't need MachineState or MachineClass data. This will allow probing code to safely create multiple accelerator objects on the fly just for reporting host/accelerator capabilities, for example. * accel_init_machine()/init_machine() will save the accelerator object in MachineState, and do initialization steps which still affect global state, machine state, or that need data from MachineClass or MachineState. To clarify the difference between those two steps, rename init() to init_machine(). Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-10-04accel: Move Xen registration code to xen-common.cEduardo Habkost1-1/+24
Note that this has an user-visible side-effect: instead of reporting "Xen is not supported for this target", QEMU binaries not supporting Xen will report "xen accelerator does not exist". As xen_available() always return 1 when CONFIG_XEN is enabled, we don't need to set AccelClass.available anymore. xen_enabled() is not being removed yet, but only because vl.c is still using it. This also allows us to make xen_init() static. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-05-07xen: factor out common functionsWei Liu1-0/+123
So common functions used by both HVM and PV are factored out from xen-all.c to xen-common.c. Finally rename xen-all.c to xen-hvm.c, as those functions are only useful to HVM guest. Create *-stub files and modify Makefile.target to reflect the changes. Signed-off-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>