cb988a10 | 04-Sep-2024 |
Edgar E. Iglesias <edgar.iglesias@amd.com> |
hw/xen: xenpvh: Disable buffered IOREQs for ARM
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
hw/xen: xenpvh: Disable buffered IOREQs for ARM
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>
show more ...
|
6ece1df9 | 10-May-2024 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/xen: Register framebuffer backend via xen_backend_init()
Align the framebuffer backend with the other legacy ones, register it via xen_backend_init() when '-vga xenfb' is used. It is safe because
hw/xen: Register framebuffer backend via xen_backend_init()
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>
show more ...
|
19c2d53c | 10-May-2024 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/xen: Constify xenstore_be::XenDevOps
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:
hw/xen: Constify xenstore_be::XenDevOps
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>
show more ...
|
f28b958c | 10-Nov-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/xen: Extract 'xen_igd.h' from 'xen_pt.h'
"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 c
hw/xen: Extract 'xen_igd.h' from 'xen_pt.h'
"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>
show more ...
|
c10b4b3c | 17-Oct-2023 |
David Woodhouse <dwmw@amazon.co.uk> |
hw/i386/pc: support '-nic' for xen-net-device
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 wher
hw/i386/pc: support '-nic' for xen-net-device
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>
show more ...
|
a72ccc7f | 16-Oct-2023 |
David Woodhouse <dwmw@amazon.co.uk> |
hw/xen: add support for Xen primary console in emulated mode
The primary console is special because the toolstack maps a page into the guest for its ring, and also allocates the guest-side event cha
hw/xen: add support for Xen primary console in emulated mode
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>
show more ...
|
eb6ae7a6 | 16-Oct-2023 |
David Woodhouse <dwmw@amazon.co.uk> |
hw/xen: do not repeatedly try to create a failing backend device
If xen_backend_device_create() fails to instantiate a device, the XenBus code will just keep trying over and over again each time the
hw/xen: do not repeatedly try to create a failing backend device
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>
show more ...
|
523b6b3a | 14-Oct-2023 |
David Woodhouse <dwmw@amazon.co.uk> |
hw/xen: add get_frontend_path() method to XenDeviceClass
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
hw/xen: add get_frontend_path() method to XenDeviceClass
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>
show more ...
|
d3256f88 | 16-Oct-2023 |
David Woodhouse <dwmw@amazon.co.uk> |
hw/xen: automatically assign device index to block devices
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
hw/xen: automatically assign device index to block devices
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>
show more ...
|
56014219 | 29-Aug-2023 |
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> |
xen_arm: Initialize RAM and add hi/low memory regions
In order to use virtio backends we need to initialize RAM for the xen-mapcache (which is responsible for mapping guest memory using foreign mapp
xen_arm: Initialize RAM and add hi/low memory regions
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>
show more ...
|