aboutsummaryrefslogtreecommitdiff
path: root/include/hw/xen
AgeCommit message (Collapse)AuthorFilesLines
2025-07-15hw/xen/arch_hvm: Unify x86 and ARM variantsPhilippe Mathieu-Daudé1-4/+10
As each target declares the same prototypes, we can use a single header, removing the TARGET_XXX uses. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Message-Id: <20250513171737.74386-1-philmd@linaro.org>
2025-05-09include/hw/xen/interface/io/blkif.h: fix "the the" typo in commentMichael Tokarev1-1/+1
Suggested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2025-04-23include/system: Move exec/memory.h to system/memory.hRichard Henderson1-1/+1
Convert the existing includes with sed -i ,exec/memory.h,system/memory.h,g Move the include within cpu-all.h into a !CONFIG_USER_ONLY block. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-03-11hw/xen/hvm: Fix Aarch64 typoPhilippe Mathieu-Daudé1-1/+1
There is no TARGET_ARM_64 definition. Luckily enough, when TARGET_AARCH64 is defined, TARGET_ARM also is. Fixes: 733766cd373 ("hw/arm: introduce xenpvh machine") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20250305153929.43687-2-philmd@linaro.org>
2025-03-04hw/xen/xen-legacy-backend: Remove unused 'net/net.h' headerPhilippe Mathieu-Daudé1-1/+0
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech> Message-Id: <20250218162618.46167-8-philmd@linaro.org>
2025-03-04hw/xen/xen-bus: Reduce included headersPhilippe Mathieu-Daudé1-1/+2
Have "hw/xen/xen-bus" include the bare minimal set of headers. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech> Message-Id: <20250218162618.46167-7-philmd@linaro.org>
2025-03-04hw/xen/xen-hvm: Reduce included headersPhilippe Mathieu-Daudé1-11/+3
Have "hw/xen/xen-hvm-common.h" include the bare minimal set of headers. Adapt sources to avoid errors when refactoring unrelated headers such: include/hw/xen/xen-hvm-common.h:71:5: error: unknown type name ‘xenevtchn_handle’ 71 | xenevtchn_handle *xce_handle; | ^~~~~~~~~~~~~~~~ hw/xen/xen-hvm-common.c: In function ‘cpu_get_ioreq’: hw/xen/xen-hvm-common.c:227:13: error: implicit declaration of function ‘hw_error’ 227 | hw_error("Fatal error while trying to get io event!\n"); | ^~~~~~~~ | herror hw/xen/xen-hvm-common.c: In function ‘handle_ioreq’: hw/xen/xen-hvm-common.c:446:34: error: ‘target_ulong’ undeclared (first use in this function) 446 | (req->size < sizeof (target_ulong))) { | ^~~~~~~~~~~~ hw/i386/xen/xen-hvm.c: In function ‘xen_add_to_physmap’: hw/i386/xen/xen-hvm.c:298:22: error: implicit declaration of function ‘xen_replace_cache_entry’ 298 | uint8_t *p = xen_replace_cache_entry(phys_offset, start_addr, size); | ^~~~~~~~~~~~~~~~~~~~~~~ hw/i386/xen/xen-hvm.c:314:9: error: implicit declaration of function 'error_report' is invalid in C99 314 | error_report("relocate_memory %lu pages from GFN %"HWADDR_PRIx ^~~~~~~~~~~~ hw/i386/xen/xen-hvm.c: In function ‘xen_log_global_start’: hw/i386/xen/xen-hvm.c:465:9: error: implicit declaration of function ‘xen_enabled’ 465 | if (xen_enabled()) { | ^~~~~~~~~~~ hw/i386/xen/xen-hvm.c: In function ‘regs_to_cpu’: hw/i386/xen/xen-hvm.c:487:5: error: unknown type name ‘X86CPU’ 487 | X86CPU *cpu; | ^~~~~~ hw/i386/xen/xen-hvm.c:492:15: error: ‘R_EAX’ undeclared (first use in this function) 492 | env->regs[R_EAX] = req->data; | ^~~~~ | REG_RAX Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech> Message-Id: <20250218162618.46167-6-philmd@linaro.org>
2025-03-04hw/xen/xen-pvh: Reduce included headersPhilippe Mathieu-Daudé1-4/+4
Have "hw/xen/xen-pvh-common.h" include the bare minimal set of headers. Adapt sources to avoid errors when refactoring unrelated headers such: hw/i386/xen/xen-pvh.c: In function ‘xen_pvh_machine_class_init’: hw/i386/xen/xen-pvh.c:84:28: error: ‘TARGET_DEFAULT_CPU_TYPE’ undeclared (first use in this function) 84 | mc->default_cpu_type = TARGET_DEFAULT_CPU_TYPE; | ^~~~~~~~~~~~~~~~~~~~~~~ hw/xen/xen-pvh-common.c: In function ‘xen_pvh_init’: hw/xen/xen-pvh-common.c:217:43: error: ‘MiB’ undeclared (first use in this function) 217 | if (s->cfg.pci_ecam.size != 256 * MiB) { | ^~~ hw/xen/xen-hvm-common.c:18:6: error: no previous prototype for ‘xen_mr_is_memory’ [-Werror=missing-prototypes] 18 | bool xen_mr_is_memory(MemoryRegion *mr) | ^~~~~~~~~~~~~~~~ Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Message-Id: <20250218162618.46167-5-philmd@linaro.org>
2025-02-16hw/xen: Have legacy Xen backend inherit from DYNAMIC_SYS_BUS_DEVICEPhilippe Mathieu-Daudé1-2/+3
Because the legacy Xen backend devices can optionally be plugged on the TYPE_PLATFORM_BUS_DEVICE, have it inherit TYPE_DYNAMIC_SYS_BUS_DEVICE. Remove the implicit TYPE_XENSYSDEV instance_size. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alexander Graf <graf@amazon.com> Tested-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20250125181343.59151-10-philmd@linaro.org>
2025-01-15xen: do not use '%ms' scanf specifierRoger Pau Monne1-0/+1
The 'm' parameter used to request auto-allocation of the destination variable is not supported on FreeBSD, and as such leads to failures to parse. What's more, the current usage of '%ms' with xs_node_scanf() is pointless, as it just leads to a double allocation of the same string. Instead use xs_node_read() to read the whole xenstore node. Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create XenDevice-s...') Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
2025-01-15hw/xen: Add xs_node_read() helper functionDavid Woodhouse1-0/+9
This returns the full contents of the node, having created the node path from the printf-style format string provided in its arguments. This will save various callers from having to do so for themselves (and from using xs_node_scanf() with the non-portable %ms format string. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> [remove double newline and constify trace parameters] Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
2024-12-20hw/xen: Remove unnecessary 'exec/cpu-common.h' headerPhilippe Mathieu-Daudé1-2/+0
Nothing requires definitions from "exec/cpu-common.h", do not include this header. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20241217151305.29196-2-philmd@linaro.org>
2024-12-20include: Rename sysemu/ -> system/Philippe Mathieu-Daudé2-5/+5
Headers in include/sysemu/ are not only related to system *emulation*, they are also used by virtualization. Rename as system/ which is clearer. Files renamed manually then mechanical change using sed tool. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Lei Yang <leiyang@redhat.com> Message-Id: <20241203172445.28576-1-philmd@linaro.org>
2024-10-03hw/xen: xenpvh: Disable buffered IOREQs for ARMEdgar E. Iglesias1-0/+3
Add a way to enable/disable buffered IOREQs for PVH machines and disable them for ARM. ARM does not support buffered IOREQ's nor the legacy way to map IOREQ info pages. See the following for more details: https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=2fbd7e609e1803ac5e5c26e22aa8e4b5a6cddbb1 https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/ioreq.c;h=2e829d2e7f3760401b96fa7c930e2015fb1cf463;hb=HEAD#l138 Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
2024-10-03hw/xen: Expose handle_bufioreq in xen_register_ioreqEdgar E. Iglesias2-1/+5
Expose handle_bufioreq in xen_register_ioreq(). This is to allow machines to enable or disable buffered ioreqs. No functional change since all callers still set it to HVM_IOREQSRV_BUFIOREQ_ATOMIC. Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
2024-10-03hw/xen: Remove deadcodeDr. David Alan Gilbert1-5/+0
xen_be_copy_grant_refs is unused since 2019's 19f87870ba ("xen: remove the legacy 'xen_disk' backend") xen_config_dev_console is unused since 2018's 6d7c06c213 ("Remove broken Xen PV domain builder") Remove them. Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org> Acked-by: Anthony PERARD <anthony.perard@vates.tech> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
2024-09-04hw/xen: pvh-common: Add support for creating PCIe/GPEXEdgar E. Iglesias1-0/+29
Add support for optionally creating a PCIe/GPEX controller. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-09-04hw/arm: xenpvh: Break out a common PVH machineEdgar E. Iglesias1-0/+59
Break out a common Xen PVH machine in preparation for adding a x86 Xen PVH machine. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-07-01hw/xen: detect when running inside stubdomainMarek Marczykowski-Górecki1-0/+1
Introduce global xen_is_stubdomain variable when qemu is running inside a stubdomain instead of dom0. This will be relevant for subsequent patches, as few things like accessing PCI config space need to be done differently. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <e66aa97dca5120f22e015c19710b2ff04f525720.1711506237.git-series.marmarek@invisiblethingslab.com> Signed-off-by: Anthony PERARD <anthony@xenproject.org>
2024-06-09xen: mapcache: Add support for grant mappingsEdgar E. Iglesias1-0/+3
Add a second mapcache for grant mappings. The mapcache for grants needs to work with XC_PAGE_SIZE granularity since we can't map larger ranges than what has been granted to us. Like with foreign mappings (xen_memory), machines using grants are expected to initialize the xen_grants MR and map it into their address-map accordingly. CC: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-06-04hw/xen: Register framebuffer backend via xen_backend_init()Philippe Mathieu-Daudé1-3/+0
Align the framebuffer backend with the other legacy ones, register it via xen_backend_init() when '-vga xenfb' is used. It is safe because MODULE_INIT_XEN_BACKEND is called in xen_bus_realize(), long after CLI processing initialized the vga_interface_type variable. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20240510104908.76908-8-philmd@linaro.org>
2024-06-04hw/xen: Make XenDevOps structures constPhilippe Mathieu-Daudé1-1/+1
Keep XenDevOps structures in .rodata. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20240510104908.76908-5-philmd@linaro.org>
2024-06-04hw/xen: Constify xenstore_be::XenDevOpsPhilippe Mathieu-Daudé1-1/+1
XenDevOps @ops is not updated, mark it const. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20240510104908.76908-4-philmd@linaro.org>
2024-06-04hw/xen: Constify XenLegacyDevice::XenDevOpsPhilippe Mathieu-Daudé1-1/+1
XenDevOps @ops is not updated, mark it const. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20240510104908.76908-3-philmd@linaro.org>
2024-05-10xen: register legacy backends via xen_backend_initPaolo Bonzini2-13/+2
It is okay to register legacy backends in the middle of xen_bus_init(). All that the registration does is record the existence of the backend in xenstore. This makes it possible to remove them from the build without introducing undefined symbols in xen_be_init(). It also removes the need for the backend_register callback, whose only purpose is to avoid registering nonfunctional backends. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240509170044.190795-8-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-03-09hw/xen: Extract 'xen_igd.h' from 'xen_pt.h'Philippe Mathieu-Daudé1-0/+33
"hw/xen/xen_pt.h" requires "hw/xen/xen_native.h" which is target specific. It also declares IGD methods, which are not target specific. Target-agnostic code can use IGD methods. To allow that, extract these methos into a new "hw/xen/xen_igd.h" header. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Message-Id: <20231114143816.71079-18-philmd@linaro.org>
2024-03-09hw/xen: Rename 'ram_memory' global variable as 'xen_memory'Philippe Mathieu-Daudé1-1/+1
To avoid a potential global variable shadow in hw/i386/pc_piix.c::pc_init1(), rename Xen's "ram_memory" as "xen_memory". Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Message-Id: <20231114143816.71079-11-philmd@linaro.org>
2024-02-02hw/xen: use qemu_create_nic_bus_devices() to instantiate Xen NICsDavid Woodhouse2-2/+1
When instantiating XenBus itself, for each NIC which is configured with either the model unspecified, or set to to "xen" or "xen-net-device", create a corresponding xen-net-device for it. Now we can revert the previous more hackish version which relied on the platform code explicitly registering the NICs on its own XenBus, having returned the BusState* from xen_bus_init() itself. This also fixes the setup for Xen PV guests, which was previously broken in various ways and never actually managed to peer with the netdev. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2024-01-30include: Clean up includesPeter Maydell1-1/+0
This commit was created with scripts/clean-includes: ./scripts/clean-includes --git include include/*/*.h include/*/*/*.h All .c should include qemu/osdep.h first. The script performs three related cleanups: * Ensure .c files include qemu/osdep.h first. * Including it in a .h is redundant, since the .c already includes it. Drop such inclusions. * Likewise, including headers qemu/osdep.h includes is redundant. Drop these, too. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-12-12xen: fix condition for skipping virtio-mmio definesPaolo Bonzini1-1/+1
GUEST_VIRTIO_MMIO_* was added in Xen 4.17, so only define them for CONFIG_XEN_CTRL_INTERFACE_VERSIONs up to 4.16. Reported-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-07Xen: Fix xen_set_irq() and xendevicemodel_set_irq_level()Vikram Garhwal1-2/+2
Remove '=' from 'if CONFIG_XEN_CTRL_INTERFACE_VERSION <= 41500'. Because xendevicemodel_set_irq_level() was introduced in 4.15 version. Also, update xendevicemodel_set_irq_level() to return -1 for older versions. Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2023-11-07hw/i386/pc: support '-nic' for xen-net-deviceDavid Woodhouse1-1/+1
The default NIC creation seems a bit hackish to me. I don't understand why each platform has to call pci_nic_init_nofail() from a point in the code where it actually has a pointer to the PCI bus, and then we have the special cases for things like ne2k_isa. If qmp_device_add() can *find* the appropriate bus and instantiate the device on it, why can't we just do that from generic code for creating the default NICs too? But that isn't a yak I want to shave today. Add a xenbus field to the PCMachineState so that it can make its way from pc_basic_device_init() to pc_nic_init() and be handled as a special case like ne2k_isa is. Now we can launch emulated Xen guests with '-nic user'. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-11-07hw/xen: add support for Xen primary console in emulated modeDavid Woodhouse1-0/+1
The primary console is special because the toolstack maps a page into the guest for its ring, and also allocates the guest-side event channel. The guest's grant table is even primed to export that page using a known grant ref#. Add support for all that in emulated mode, so that we can have a primary console. For reasons unclear, the backends running under real Xen don't just use a mapping of the well-known GNTTAB_RESERVED_CONSOLE grant ref (which would also be in the ring-ref node in XenStore). Instead, the toolstack sets the ring-ref node of the primary console to the GFN of the guest page. The backend is expected to handle that special case and map it with foreignmem operations instead. We don't have an implementation of foreignmem ops for emulated Xen mode, so just make it map GNTTAB_RESERVED_CONSOLE instead. This would probably work for real Xen too, but we can't work out how to make real Xen create a primary console of type "ioemu" to make QEMU drive it, so we can't test that; might as well leave it as it is for now under Xen. Now at last we can boot the Xen PV shim and run PV kernels in QEMU. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-11-07hw/xen: do not repeatedly try to create a failing backend deviceDavid Woodhouse1-0/+1
If xen_backend_device_create() fails to instantiate a device, the XenBus code will just keep trying over and over again each time the bus is re-enumerated, as long as the backend appears online and in XenbusStateInitialising. The only thing which prevents the XenBus code from recreating duplicates of devices which already exist, is the fact that xen_device_realize() sets the backend state to XenbusStateInitWait. If the attempt to create the device doesn't get *that* far, that's when it will keep getting retried. My first thought was to handle errors by setting the backend state to XenbusStateClosed, but that doesn't work for XenConsole which wants to *ignore* any device of type != "ioemu" completely. So, make xen_backend_device_create() *keep* the XenBackendInstance for a failed device, and provide a new xen_backend_exists() function to allow xen_bus_type_enumerate() to check whether one already exists before creating a new one. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-11-07hw/xen: add get_frontend_path() method to XenDeviceClassDavid Woodhouse1-0/+2
The primary Xen console is special. The guest's side is set up for it by the toolstack automatically and not by the standard PV init sequence. Accordingly, its *frontend* doesn't appear in …/device/console/0 either; instead it appears under …/console in the guest's XenStore node. To allow the Xen console driver to override the frontend path for the primary console, add a method to the XenDeviceClass which can be used instead of the standard xen_device_get_frontend_path() Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-11-07hw/xen: automatically assign device index to block devicesDavid Woodhouse1-1/+0
There's no need to force the user to assign a vdev. We can automatically assign one, starting at xvda and searching until we find the first disk name that's unused. This means we can now allow '-drive if=xen,file=xxx' to work without an explicit separate -driver argument, just like if=virtio. Rip out the legacy handling from the xenpv machine, which was scribbling over any disks configured by the toolstack, and didn't work with anything but raw images. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Acked-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org>
2023-11-07include: update Xen public headers to Xen 4.17.2 releaseDavid Woodhouse28-522/+123
... in order to advertise the XEN_HVM_CPUID_UPCALL_VECTOR feature, which will come in a subsequent commit. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Acked-by: Paul Durrant <paul@xen.org>
2023-08-30xen_arm: Initialize RAM and add hi/low memory regionsOleksandr Tyshchenko1-0/+8
In order to use virtio backends we need to initialize RAM for the xen-mapcache (which is responsible for mapping guest memory using foreign mapping) to work. Calculate and add hi/low memory regions based on machine->ram_size. Use the constants defined in public header arch-arm.h to be aligned with the xen toolstack. While using this machine, the toolstack should then pass real ram_size using "-m" arg. If "-m" is not given, create a QEMU machine without IOREQ and other emulated devices like TPM and VIRTIO. This is done to keep this QEMU machine usable for /etc/init.d/xencommons. Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
2023-08-30xen_arm: Create virtio-mmio devices during initializationOleksandr Tyshchenko1-0/+16
In order to use virtio backends we need to allocate virtio-mmio parameters (irq and base) and register corresponding buses. Use the constants defined in public header arch-arm.h to be aligned with the toolstack. So the number of current supported virtio-mmio devices is 10. For the interrupts triggering use already existing on Arm device-model hypercall. The toolstack should then insert the same amount of device nodes into guest device-tree. Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
2023-08-01xen: Don't pass MemoryListener around by valuePeter Maydell1-1/+1
Coverity points out (CID 1513106, 1513107) that MemoryListener is a 192 byte struct which we are passing around by value. Switch to passing a const pointer into xen_register_ioreq() and then to xen_do_ioreq_register(). We can also make the file-scope MemoryListener variables const, since nothing changes them. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230718101057.1110979-1-peter.maydell@linaro.org> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-06-15hw/arm: introduce xenpvh machineVikram Garhwal1-0/+2
Add a new machine xenpvh which creates a IOREQ server to register/connect with Xen Hypervisor. Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device, adds a TPM emulator and connects to swtpm running on host machine via chardev socket and support TPM functionalities for a guest domain. Extra command line for aarch64 xenpvh QEMU to connect to swtpm: -chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \ -tpmdev emulator,id=tpm0,chardev=chrtpm \ -machine tpm-base-addr=0x0c000000 \ swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on libtpms and provides access to TPM functionality over socket, chardev and CUSE interface. Github repo: https://github.com/stefanberger/swtpm Example for starting swtpm on host machine: mkdir /tmp/vtpm2 swtpm socket --tpmstate dir=/tmp/vtpm2 \ --ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock & Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2023-06-15include/hw/xen/xen_common: return error from xen_create_ioreq_serverStefano Stabellini1-3/+5
This is done to prepare for enabling xenpv support for ARM architecture. On ARM it is possible to have a functioning xenpv machine with only the PV backends and no IOREQ server. If the IOREQ server creation fails, continue to the PV backends initialization. Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Paul Durrant <paul@xen.org>
2023-06-15xen-hvm: reorganize xen-hvm and move common function to xen-hvm-commonStefano Stabellini2-0/+102
This patch does following: 1. creates arch_handle_ioreq() and arch_xen_set_memory(). This is done in preparation for moving most of xen-hvm code to an arch-neutral location, move the x86-specific portion of xen_set_memory to arch_xen_set_memory. Also, move handle_vmport_ioreq to arch_handle_ioreq. 2. Pure code movement: move common functions to hw/xen/xen-hvm-common.c Extract common functionalities from hw/i386/xen/xen-hvm.c and move them to hw/xen/xen-hvm-common.c. These common functions are useful for creating an IOREQ server. xen_hvm_init_pc() contains the architecture independent code for creating and mapping a IOREQ server, connecting memory and IO listeners, initializing a xen bus and registering backends. Moved this common xen code to a new function xen_register_ioreq() which can be used by both x86 and ARM machines. Following functions are moved to hw/xen/xen-hvm-common.c: xen_vcpu_eport(), xen_vcpu_ioreq(), xen_ram_alloc(), xen_set_memory(), xen_region_add(), xen_region_del(), xen_io_add(), xen_io_del(), xen_device_realize(), xen_device_unrealize(), cpu_get_ioreq_from_shared_memory(), cpu_get_ioreq(), do_inp(), do_outp(), rw_phys_req_item(), read_phys_req_item(), write_phys_req_item(), cpu_ioreq_pio(), cpu_ioreq_move(), cpu_ioreq_config(), handle_ioreq(), handle_buffered_iopage(), handle_buffered_io(), cpu_handle_ioreq(), xen_main_loop_prepare(), xen_hvm_change_state_handler(), xen_exit_notifier(), xen_map_ioreq_server(), destroy_hvm_domain() and xen_shutdown_fatal_error() 3. Removed static type from below functions: 1. xen_region_add() 2. xen_region_del() 3. xen_io_add() 4. xen_io_del() 5. xen_device_realize() 6. xen_device_unrealize() 7. xen_hvm_change_state_handler() 8. cpu_ioreq_pio() 9. xen_exit_notifier() 4. Replace TARGET_PAGE_SIZE with XC_PAGE_SIZE to match the page side with Xen. Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
2023-06-07include/hw/xen/xen: Rename xen_piix3_set_irq() to xen_intx_set_irq()Bernhard Beschow1-1/+1
xen_piix3_set_irq() isn't PIIX specific: PIIX is a single PCI device while xen_piix3_set_irq() maps multiple PCI devices to their respective IRQs, which is board-specific. Rename xen_piix3_set_irq() to communicate this. Also rename XEN_PIIX_NUM_PIRQS to XEN_IOAPIC_NUM_PIRQS since the Xen's IOAPIC rather than PIIX has this many interrupt routes. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Tested-by: Chuck Zmudzinski <brchuckz@aol.com> Message-Id: <20230312120221.99183-2-shentey@gmail.com> Message-Id: <20230403074124.3925-2-shentey@gmail.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-06-07xen: Drop support for Xen versions below 4.7.1David Woodhouse1-106/+1
In restructuring to allow for internal emulation of Xen functionality, I broke compatibility for Xen 4.6 and earlier. Fix this by explicitly removing support for anything older than 4.7.1, which is also ancient but it does still build, and the compatibility support for it is fairly unintrusive. Fixes: 15e283c5b684 ("hw/xen: Add foreignmem operations to allow redirection to internal emulation") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20230412185102.441523-4-dwmw2@infradead.org> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-03-07hw/xen: Rename xen_common.h to xen_native.hDavid Woodhouse3-12/+23
This header is now only for native Xen code, not PV backends that may be used in Xen emulation. Since the toolstack libraries may depend on the specific version of Xen headers that they pull in (and will set the __XEN_TOOLS__ macro to enable internal definitions that they depend on), the rule is that xen_native.h (and thus the toolstack library headers) must be included *before* any of the headers in include/hw/xen/interface. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-07hw/xen: Move xenstore_store_pv_console_info to xen_console.cDavid Woodhouse1-2/+0
There's no need for this to be in the Xen accel code, and as we want to use the Xen console support with KVM-emulated Xen we'll want to have a platform-agnostic version of it. Make it use GString to build up the path while we're at it. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-07hw/xen: Add xenstore operations to allow redirection to internal emulationPaul Durrant6-32/+183
Signed-off-by: Paul Durrant <pdurrant@amazon.com> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-07hw/xen: Add foreignmem operations to allow redirection to internal emulationDavid Woodhouse2-13/+26
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-07hw/xen: Pass grant ref to gnttab unmap operationDavid Woodhouse3-7/+8
The previous commit introduced redirectable gnttab operations fairly much like-for-like, with the exception of the extra arguments to the ->open() call which were always NULL/0 anyway. This *changes* the arguments to the ->unmap() operation to include the original ref# that was mapped. Under real Xen it isn't necessary; all we need to do from QEMU is munmap(), then the kernel will release the grant, and Xen does the tracking/refcounting for the guest. When we have emulated grant tables though, we need to do all that for ourselves. So let's have the back ends keep track of what they mapped and pass it in to the ->unmap() method for us. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>