- Mar 23, 2023
-
-
David Woodhouse authored
When dm_restrict is set, QEMU isn't permitted to update the XenStore node to indicate its running status. Previously, the xs_write() call would fail but the failure was ignored. However, in refactoring to allow for emulated XenStore operations, a new call to xs_open() was added. That one didn't fail gracefully, causing a fatal error when running in dm_restrict mode. Partially revert the offending patch, removing the additional call to xs_open() because the global 'xenstore' variable is still available; it just needs to be used with qemu_xen_xs_write() now instead of directly with the xs_write() libxenstore function. Also make the whole thing conditional on !xen_domid_restrict. There's no point even registering the state change handler to attempt to update the XenStore node when we know it's destined to fail. Fixes: ba2a92db ("hw/xen: Add xenstore operations to allow redirection to internal emulation") Reported-by:
Jason Andryuk <jandryuk@gmail.com> Co-developed-by:
Jason Andryuk <jandryuk@gmail.com> Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Reviewed-by:
Paul Durrant <paul@xen.org> Tested-by:
Jason Andryuk <jandryuk@gmail.com> Message-Id: <1f141995bb61af32c2867ef5559e253f39b0949c.camel@infradead.org> Signed-off-by:
Anthony PERARD <anthony.perard@citrix.com>
-
- Mar 07, 2023
-
-
David Woodhouse authored
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>
-
David Woodhouse authored
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>
-
Paul Durrant authored
Signed-off-by:
Paul Durrant <pdurrant@amazon.com> Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Reviewed-by:
Paul Durrant <paul@xen.org>
-
- Mar 01, 2023
-
-
David Woodhouse authored
Also set XEN_ATTACH mode in xen_init() to reflect the truth; not that anyone ever cared before. It was *only* ever checked in xen_init_pv() before. Suggested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Reviewed-by:
Paul Durrant <paul@xen.org>
-
- Feb 27, 2023
-
-
Philippe Mathieu-Daudé authored
Unused since introduction in commit 04b0de0e ("xen: factor out common functions"). Signed-off-by:
Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Acked-by:
Paul Durrant <paul@xen.org> Message-Id: <20230215153451.30626-1-philmd@linaro.org>
-
- Mar 09, 2021
-
-
Philippe Mathieu-Daudé authored
The 'running' argument from VMChangeStateHandler does not require other value than 0 / 1. Make it a plain boolean. Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Acked-by:
David Gibson <david@gibson.dropbear.id.au> Message-Id: <20210111152020.1422021-3-philmd@redhat.com> Signed-off-by:
Laurent Vivier <laurent@vivier.eu>
-
- Feb 05, 2021
-
-
Claudio Fontana authored
This will allow us to centralize the registration of the cpus.c module accelerator operations (in accel/accel-softmmu.c), and trigger it automatically using object hierarchy lookup from the new accel_init_interfaces() initialization step, depending just on which accelerators are available in the code. Rename all tcg-cpus.c, kvm-cpus.c, etc to tcg-accel-ops.c, kvm-accel-ops.c, etc, matching the object type names. Signed-off-by:
Claudio Fontana <cfontana@suse.de> Message-Id: <20210204163931.7358-18-cfontana@suse.de> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org>
-
Claudio Fontana authored
Signed-off-by:
Claudio Fontana <cfontana@suse.de> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> [claudio: rebased on Richard's splitwx work] Signed-off-by:
Claudio Fontana <cfontana@suse.de> Message-Id: <20210204163931.7358-17-cfontana@suse.de> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org>
-
- Oct 24, 2020
-
-
Jason Andryuk authored
Xen was broken by commit 1583a389 ("cpus: extract out qtest-specific code to accel/qtest"). Xen relied on qemu_init_vcpu() calling qemu_dummy_start_vcpu() in the default case, but that was replaced by g_assert_not_reached(). Add a minimal "CpusAccel" for Xen using the dummy-cpus implementation used by qtest. Signed-off-by:
Jason Andryuk <jandryuk@gmail.com> Message-Id: <20201013140511.5681-4-jandryuk@gmail.com> Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
Claudio Fontana <cfontana@suse.de> Acked-by:
Anthony PERARD <anthony.perard@citrix.com> Signed-off-by:
Thomas Huth <thuth@redhat.com>
-
- Aug 21, 2020
-
-
Marc-André Lureau authored
Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Aug 04, 2020
-
-
Philippe Mathieu-Daudé authored
CONFIG_XEN is generated by configure and stored in "config-target.h", which is (obviously) only include for target-specific objects. This is a problem for target-agnostic objects as CONFIG_XEN is never defined and xen_enabled() is always inlined as 'false'. Fix by following the KVM schema, defining CONFIG_XEN_IS_POSSIBLE when we don't know to force the call of the non-inlined function, returning the xen_allowed boolean. Fixes: da278d58 ("accel: Move Xen accelerator code under accel/xen/") Reported-by:
Paul Durrant <pdurrant@amazon.com> Suggested-by:
Peter Maydell <peter.maydell@linaro.org> Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by:
Paul Durrant <paul@xen.org> Reviewed-by:
Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200804074930.13104-2-philmd@redhat.com> Signed-off-by:
Anthony PERARD <anthony.perard@citrix.com>
-
- Jun 12, 2020
-
-
Anthony PERARD authored
Xen PCI passthrough support may not be available and thus the global variable "has_igd_gfx_passthru" might be compiled out. Common code should not access it in that case. Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in xen-common.c so this patch instead move access to the has_igd_gfx_passthru variable via function and those functions are also implemented as stubs. The stubs will be used when QEMU is built without passthrough support. Now, when one will want to enable igd-passthru via the -machine property, they will get an error message if QEMU is built without passthrough support. Fixes: 46472d82 ('xen: convert "-machine igd-passthru" to an accelerator property') Reported-by:
Roger Pau Monné <roger.pau@citrix.com> Signed-off-by:
Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200603160442.3151170-1-anthony.perard@citrix.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jun 10, 2020
-
-
Philippe Mathieu-Daudé authored
This code is not related to hardware emulation. Move it under accel/ with the other hypervisors. Reviewed-by:
Paul Durrant <paul@xen.org> Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200508100222.7112-1-philmd@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-