aboutsummaryrefslogtreecommitdiff
path: root/hw/i386/pc.c
diff options
context:
space:
mode:
authorDavid Woodhouse <dwmw@amazon.co.uk>2023-04-12 19:50:58 +0100
committerAnthony PERARD <anthony.perard@citrix.com>2023-06-07 15:07:10 +0100
commiteeedfe6c6316e8c0d58becc427e12aceb4cb3ad3 (patch)
treea22f2b96236194829559d8e6716a68f249207c03 /hw/i386/pc.c
parentf5e6786de4815751b0a3d2235c760361f228ea48 (diff)
hw/xen: Simplify emulated Xen platform init
I initially put the basic platform init (overlay pages, grant tables, event channels) into mc->kvm_type because that was the earliest place that could sensibly test for xen_mode==XEN_EMULATE. The intent was to do this early enough that we could then initialise the XenBus and other parts which would have depended on them, from a generic location for both Xen and KVM/Xen in the PC-specific code, as seen in https://lore.kernel.org/qemu-devel/20230116221919.1124201-16-dwmw2@infradead.org/ However, then the Xen on Arm patches came along, and *they* wanted to do the XenBus init from a 'generic' Xen-specific location instead: https://lore.kernel.org/qemu-devel/20230210222729.957168-4-sstabellini@kernel.org/ Since there's no generic location that covers all three, I conceded to do it for XEN_EMULATE mode in pc_basic_devices_init(). And now there's absolutely no point in having some of the platform init done from pc_machine_kvm_type(); we can move it all up to live in a single place in pc_basic_devices_init(). This has the added benefit that we can drop the separate xen_evtchn_connect_gsis() function completely, and pass just the system GSIs in directly to xen_evtchn_create(). While I'm at it, it does no harm to explicitly pass in the *number* of said GSIs, because it does make me twitch a bit to pass an array of impicit size. During the lifetime of the KVM/Xen patchset, that had already changed (albeit just cosmetically) from GSI_NUM_PINS to IOAPIC_NUM_PINS. And document a bit better that this is for the *output* GSI for raising CPU0's events when the per-CPU vector isn't available. The fact that we create a whole set of them and then only waggle the one we're told to, instead of having a single output and only *connecting* it to the GSI that it should be connected to, is still non-intuitive for me. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20230412185102.441523-2-dwmw2@infradead.org> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Diffstat (limited to 'hw/i386/pc.c')
-rw-r--r--hw/i386/pc.c13
1 files changed, 4 insertions, 9 deletions
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index bb62c994fa..fc52772fdd 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1332,7 +1332,10 @@ void pc_basic_device_init(struct PCMachineState *pcms,
#ifdef CONFIG_XEN_EMU
if (xen_mode == XEN_EMULATE) {
- xen_evtchn_connect_gsis(gsi);
+ xen_overlay_create();
+ xen_evtchn_create(IOAPIC_NUM_PINS, gsi);
+ xen_gnttab_create();
+ xen_xenstore_create();
if (pcms->bus) {
pci_create_simple(pcms->bus, -1, "xen-platform");
}
@@ -1882,14 +1885,6 @@ static void pc_machine_initfn(Object *obj)
int pc_machine_kvm_type(MachineState *machine, const char *kvm_type)
{
-#ifdef CONFIG_XEN_EMU
- if (xen_mode == XEN_EMULATE) {
- xen_overlay_create();
- xen_evtchn_create();
- xen_gnttab_create();
- xen_xenstore_create();
- }
-#endif
return 0;
}