q35: change defaults for kernel irqchip and IR

Starting from QEMU 4.0, let's specify "split" as the default value for kernel-irqchip.

So for QEMU>=4.0 we'll have: allowed=Y,required=N,split=Y
for QEMU<=3.1 we'll have: allowed=Y,required=N,split=N (omitting all the "kernel_irqchip_" prefix)

Note that this will let the default q35 machine type to depend on Linux version 4.4 or newer because that's where split irqchip is introduced in kernel. But it's fine since we're boosting supported Linux version for QEMU 4.0 to around Linux 4.5. For more information please refer to the discussion on AMD's RDTSCP:

https://lore.kernel.org/lkml/[email protected]/

Signed-off-by Peter Xu <[email protected]>

Starting from QEMU 4.0, let's specify "split" as the default value for kernel-irqchip.

So for QEMU>=4.0 we'll have: allowed=Y,required=N,split=Y
for QEMU<=3.1 we'll have: allowed=Y,required=N,split=N (omitting all the "kernel_irqchip_" prefix)

Note that this will let the default q35 machine type to depend on Linux version 4.4 or newer because that's where split irqchip is introduced in kernel. But it's fine since we're boosting supported Linux version for QEMU 4.0 to around Linux 4.5. For more information please refer to the discussion on AMD's RDTSCP:

https://lore.kernel.org/lkml/[email protected]/

Quoted 7 lines · On Thu, 20 Dec 2018 13:40:35 +0800 Peter Xu <[email protected]> wrote:

Starting from QEMU 4.0, let's specify "split" as the default value for kernel-irqchip.

So for QEMU>=4.0 we'll have: allowed=Y,required=N,split=Y
for QEMU<=3.1 we'll have: allowed=Y,required=N,split=N (omitting all the "kernel_irqchip_" prefix)

Quoted 7 lines

Note that this will let the default q35 machine type to depend on Linux version 4.4 or newer because that's where split irqchip is introduced in kernel. But it's fine since we're boosting supported Linux version for QEMU 4.0 to around Linux 4.5. For more information please refer to the discussion on AMD's RDTSCP:

https://lore.kernel.org/lkml/[email protected]/

It looks like this broke INTx for vfio-pci, see:

https://bugs.launchpad.net/qemu/+bug/1826422

In my testing it looks like KVM advertises supporting the KVM_IRQFD resample feature, but vfio never gets the unmask notification, so the device remains with DisINTx set and no further interrupts are generated. Do we expect KVM's IRQFD with resampler to work in the split IRQ mode? We can certainly hope that "high performance" devices use MSI or MSI/X, but this would be quite a performance regression with split mode if our userspace bypass for INTx goes away. Thanks,

Quoted 8 lines

In my testing it looks like KVM advertises supporting the KVM_IRQFD resample feature, but vfio never gets the unmask notification, so the device remains with DisINTx set and no further interrupts are generated. Do we expect KVM's IRQFD with resampler to work in the split IRQ mode? We can certainly hope that "high performance" devices use MSI or MSI/X, but this would be quite a performance regression with split mode if our userspace bypass for INTx goes away. Thanks,

arch/x86/kvm/lapic.c:kvm_ioapic_send_eoi() dumps to userspace before kvm_ioapic_update_eoi() can handle the irq_ack_notifier_list via kvm_notify_acked_gsi(),

so it looks like KVM really ought to return an
error when trying to register a resample IRQFD when irqchip_split(), but do we have better options? EOI handling in QEMU is pretty much non-existent and even if it was in place, it's a big performance regression for vfio INTx handling. Is a split irqchip that retains performant resampling (EOI) support possible? Thanks,

Quoted 9 lines

Quoted 8 lines

In my testing it looks like KVM advertises supporting the KVM_IRQFD resample feature, but vfio never gets the unmask notification, so the device remains with DisINTx set and no further interrupts are generated. Do we expect KVM's IRQFD with resampler to work in the split IRQ mode? We can certainly hope that "high performance" devices use MSI or MSI/X, but this would be quite a performance regression with split mode if our userspace bypass for INTx goes away. Thanks,

Quoted 3 lines

arch/x86/kvm/lapic.c:kvm_ioapic_send_eoi() dumps to userspace before kvm_ioapic_update_eoi() can handle the irq_ack_notifier_list via kvm_notify_acked_gsi(),

That wouldn't help because kvm_ioapic_update_eoi would not even be able to access vcpu->kvm->arch.vioapic (it's NULL).

The following untested patch would signal the resamplefd in kvm_ioapic_send_eoi, before requesting the exit to userspace. However I am not sure how QEMU sets up the VFIO eventfds: if I understand correctly, when VFIO writes again to the irq eventfd, the interrupt request would not reach the userspace IOAPIC, but only the in-kernel LAPIC. That would be incorrect, and if my understanding is correct we need to trigger resampling from hw/intc/ioapic.c.

Something like:

1) VFIO uses kvm_irqchip_add_irqfd_notifier_gsi instead of KVM_IRQFD directly

2) add a NotifierList in kvm_irqchip_assign_irqfd

3) if kvm_irqchip_is_split(), register a corresponding Notifier in ioapic.c which stores the resamplefd as an EventNotifier*

4) ioapic_eoi_broadcast writes to the resamplefd

BTW, how do non-x86 platforms handle intx resampling?

Paolo

---- 8< -----
From: Paolo Bonzini <[email protected]>
Subject: [PATCH WIP] kvm: lapic: run ack notifiers for userspace IOAPIC routes

arch/x86/kvm/ioapic.h +2 -0

index ea1a4e0297da..be337e06e3fd 100644
@@ -135,4 +135,6 @@ void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu,
 			   ulong *ioapic_handled_vectors);
 void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu,
 			    ulong *ioapic_handled_vectors);
+void kvm_notify_userspace_ioapic_routes(struct kvm *kvm, int vector);
+
 #endif

arch/x86/kvm/irq_comm.c +28 -0

index 3cc3b2d130a0..46ea79a0dd8a 100644
@@ -435,6 +435,34 @@ void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu,
 	srcu_read_unlock(&kvm->irq_srcu, idx);
 }
 
+void kvm_notify_userspace_ioapic_routes(struct kvm *kvm, int vector)
+{
+        struct kvm_kernel_irq_routing_entry *entry;
+        struct kvm_irq_routing_table *table;
+        u32 i, nr_ioapic_pins;
+        int idx;
+
+        idx = srcu_read_lock(&kvm->irq_srcu);
+        table = srcu_dereference(kvm->irq_routing, &kvm->irq_srcu);
+        nr_ioapic_pins = min_t(u32, table->nr_rt_entries,
+                               kvm->arch.nr_reserved_ioapic_pins);
+
+	for (i = 0; i < nr_ioapic_pins; i++) {
+                hlist_for_each_entry(entry, &table->map[i], link) {
+                        struct kvm_lapic_irq irq;
+
+                        if (entry->type != KVM_IRQ_ROUTING_MSI)
+                                continue;
+
+			kvm_set_msi_irq(kvm, entry, &irq);
+			if (irq.level && irq.vector == vector)
+				kvm_notify_acked_gsi(kvm, i);
+		}
+	}
+
+	srcu_read_unlock(&kvm->irq_srcu, idx);
+}
+
 void kvm_arch_irq_routing_update(struct kvm *kvm)
 {
 	kvm_hv_irq_routing_update(kvm);

arch/x86/kvm/lapic.c +6 -4

index 9f089e2e09d0..8f8e76d77925 100644
@@ -1142,6 +1142,7 @@ static bool kvm_ioapic_handles_vector(struct kvm_lapic *apic, int vector)
 
 static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector)
 {
+	struct kvm_vcpu *vcpu = apic->vcpu;
 	int trigger_mode;
 
 	/* Eoi the ioapic only if the ioapic doesn't own the vector. */

@@ -1149,9 +1150,10 @@ static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector)
 		return;
 
 	/* Request a KVM exit to inform the userspace IOAPIC. */
-	if (irqchip_split(apic->vcpu->kvm)) {
-		apic->vcpu->arch.pending_ioapic_eoi = vector;
-		kvm_make_request(KVM_REQ_IOAPIC_EOI_EXIT, apic->vcpu);
+	if (irqchip_split(vcpu->kvm)) {
+		kvm_notify_userspace_ioapic_routes(vcpu->kvm, vector);
+		vcpu->arch.pending_ioapic_eoi = vector;
+		kvm_make_request(KVM_REQ_IOAPIC_EOI_EXIT, vcpu);
 		return;
 	}
 

@@ -1160,7 +1162,7 @@ static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector)
 	else
 		trigger_mode = IOAPIC_EDGE_TRIG;
 
-	kvm_ioapic_update_eoi(apic->vcpu, vector, trigger_mode);
+	kvm_ioapic_update_eoi(vcpu, vector, trigger_mode);
 }
 
 static int apic_set_eoi(struct kvm_lapic *apic)

Quoted 8 lines

so it looks like KVM really ought to return an
error when trying to register a resample IRQFD when irqchip_split(), but do we have better options? EOI handling in QEMU is pretty much non-existent and even if it was in place, it's a big performance regression for vfio INTx handling. Is a split irqchip that retains performant resampling (EOI) support possible? Thanks,

Quoted 16 lines · Paolo Bonzini

Quoted 9 lines

Quoted 8 lines

In my testing it looks like KVM advertises supporting the KVM_IRQFD resample feature, but vfio never gets the unmask notification, so the device remains with DisINTx set and no further interrupts are generated. Do we expect KVM's IRQFD with resampler to work in the split IRQ mode? We can certainly hope that "high performance" devices use MSI or MSI/X, but this would be quite a performance regression with split mode if our userspace bypass for INTx goes away. Thanks,

Quoted 3 lines

arch/x86/kvm/lapic.c:kvm_ioapic_send_eoi() dumps to userspace before kvm_ioapic_update_eoi() can handle the irq_ack_notifier_list via kvm_notify_acked_gsi(),

That wouldn't help because kvm_ioapic_update_eoi would not even be able to access vcpu->kvm->arch.vioapic (it's NULL).

Quoted 6 lines

The following untested patch would signal the resamplefd in kvm_ioapic_send_eoi, before requesting the exit to userspace. However I am not sure how QEMU sets up the VFIO eventfds: if I understand correctly, when VFIO writes again to the irq eventfd, the interrupt request would not reach the userspace IOAPIC, but only the in-kernel LAPIC. That would be incorrect, and if my understanding is correct we need to trigger resampling from hw/intc/ioapic.c.

Actually it's worse: because you're bypassing IOAPIC when raising the irq, the IOAPIC's remote_irr for example will not be set. So split irqchip currently must disable the intx fast path completely.

I guess we could also reimplement irqfd and resamplefd in the userspace IOAPIC, and run the listener in a separate thread (using "-object iothread" on the command line and AioContext in the code).

Quoted 24 lines · On Sat, 27 Apr 2019 10:09:51 +0200 Paolo Bonzini <[email protected]> wrote:

Quoted 16 lines · Paolo Bonzini

Quoted 9 lines

Quoted 8 lines

In my testing it looks like KVM advertises supporting the KVM_IRQFD resample feature, but vfio never gets the unmask notification, so the device remains with DisINTx set and no further interrupts are generated. Do we expect KVM's IRQFD with resampler to work in the split IRQ mode? We can certainly hope that "high performance" devices use MSI or MSI/X, but this would be quite a performance regression with split mode if our userspace bypass for INTx goes away. Thanks,

Quoted 3 lines

arch/x86/kvm/lapic.c:kvm_ioapic_send_eoi() dumps to userspace before kvm_ioapic_update_eoi() can handle the irq_ack_notifier_list via kvm_notify_acked_gsi(),

That wouldn't help because kvm_ioapic_update_eoi would not even be able to access vcpu->kvm->arch.vioapic (it's NULL).

Quoted 6 lines

The following untested patch would signal the resamplefd in kvm_ioapic_send_eoi, before requesting the exit to userspace. However I am not sure how QEMU sets up the VFIO eventfds: if I understand correctly, when VFIO writes again to the irq eventfd, the interrupt request would not reach the userspace IOAPIC, but only the in-kernel LAPIC. That would be incorrect, and if my understanding is correct we need to trigger resampling from hw/intc/ioapic.c.

Quoted 7 lines

Actually it's worse: because you're bypassing IOAPIC when raising the irq, the IOAPIC's remote_irr for example will not be set. So split irqchip currently must disable the intx fast path completely.

I guess we could also reimplement irqfd and resamplefd in the userspace IOAPIC, and run the listener in a separate thread (using "-object iothread" on the command line and AioContext in the code).

This sounds like a performance regression vs KVM irqchip any way we slice it. Was this change a mistake? Without KVM support, the universal support in QEMU kicks in, where device mmaps are disabled when an INTx occurs, forcing trapped access to the device, and we assume that the next access is in response to an interrupt and trigger our own internal EOI and re-enable mmaps. A timer acts as a catch-all. Needless to say, this is functional but not fast. It would be a massive performance regression for devices depending on INTx and previously using the KVM bypass to switch to this. INTx is largely considered a legacy interrupt, so non-x86 archs don't encounter it as often, S390 even explicitly disables INTx support. ARM and POWER likely just don't see a lot of these devices, but nearly all devices (except SR-IOV VFs) on x86 expect an INTx fallback mode and some drivers may run the device in INTx for compatibility. This split irqchip change was likely fine for "enterprise" users concerned only with modern high speed devices, but very much not for device assignment used for compatibility use cases or commodity hardware users.

What's a good 4.0.1 strategy to resolve this? Re-instate KVM irqchip as the Q35 default? I can't see that simply switching to current QEMU handling is a viable option for performance? What about 4.1? We could certainly improve EOI support in QEMU, there's essentially no support currently, but it seems like an uphill battle for an iothread based userspace ioapic to ever compare to KVM handling? Thanks,

Quoted 53 lines · Alex Williamson

Quoted 24 lines · On Sat, 27 Apr 2019 10:09:51 +0200 Paolo Bonzini <[email protected]> wrote:

Quoted 16 lines · Paolo Bonzini

Quoted 9 lines

Quoted 8 lines

In my testing it looks like KVM advertises supporting the KVM_IRQFD resample feature, but vfio never gets the unmask notification, so the device remains with DisINTx set and no further interrupts are generated. Do we expect KVM's IRQFD with resampler to work in the split IRQ mode? We can certainly hope that "high performance" devices use MSI or MSI/X, but this would be quite a performance regression with split mode if our userspace bypass for INTx goes away. Thanks,

Quoted 3 lines

arch/x86/kvm/lapic.c:kvm_ioapic_send_eoi() dumps to userspace before kvm_ioapic_update_eoi() can handle the irq_ack_notifier_list via kvm_notify_acked_gsi(),

That wouldn't help because kvm_ioapic_update_eoi would not even be able to access vcpu->kvm->arch.vioapic (it's NULL).

Quoted 6 lines

The following untested patch would signal the resamplefd in kvm_ioapic_send_eoi, before requesting the exit to userspace. However I am not sure how QEMU sets up the VFIO eventfds: if I understand correctly, when VFIO writes again to the irq eventfd, the interrupt request would not reach the userspace IOAPIC, but only the in-kernel LAPIC. That would be incorrect, and if my understanding is correct we need to trigger resampling from hw/intc/ioapic.c.

Quoted 7 lines

Actually it's worse: because you're bypassing IOAPIC when raising the irq, the IOAPIC's remote_irr for example will not be set. So split irqchip currently must disable the intx fast path completely.

I guess we could also reimplement irqfd and resamplefd in the userspace IOAPIC, and run the listener in a separate thread (using "-object iothread" on the command line and AioContext in the code).

This sounds like a performance regression vs KVM irqchip any way we slice it. Was this change a mistake? Without KVM support, the universal support in QEMU kicks in, where device mmaps are disabled when an INTx occurs, forcing trapped access to the device, and we assume that the next access is in response to an interrupt and trigger our own internal EOI and re-enable mmaps. A timer acts as a catch-all. Needless to say, this is functional but not fast. It would be a massive performance regression for devices depending on INTx and previously using the KVM bypass to switch to this. INTx is largely considered a legacy interrupt, so non-x86 archs don't encounter it as often, S390 even explicitly disables INTx support. ARM and POWER likely just don't see a lot of these devices, but nearly all devices (except SR-IOV VFs) on x86 expect an INTx fallback mode and some drivers may run the device in INTx for compatibility. This split irqchip change was likely fine for "enterprise" users concerned only with modern high speed devices, but very much not for device assignment used for compatibility use cases or commodity hardware users.

Quoted 6 lines

What's a good 4.0.1 strategy to resolve this? Re-instate KVM irqchip as the Q35 default? I can't see that simply switching to current QEMU handling is a viable option for performance? What about 4.1? We could certainly improve EOI support in QEMU, there's essentially no support currently, but it seems like an uphill battle for an iothread based userspace ioapic to ever compare to KVM handling? Thanks,

irqchip=split and irqchip=kernel aren't guest ABI compatible, are they? That would make it impossible to fix this in pc-q35-4.0 for a 4.0.1 update.

Quoted 7 lines

Quoted 6 lines

What's a good 4.0.1 strategy to resolve this? Re-instate KVM irqchip as the Q35 default? I can't see that simply switching to current QEMU handling is a viable option for performance? What about 4.1? We could certainly improve EOI support in QEMU, there's essentially no support currently, but it seems like an uphill battle for an iothread based userspace ioapic to ever compare to KVM handling? Thanks,

Quoted 3 lines

irqchip=split and irqchip=kernel aren't guest ABI compatible, are they? That would make it impossible to fix this in pc-q35-4.0 for a 4.0.1 update.

I suppose it would require a pc-q35-4.0.1 machine type :-\ Thanks,

On Mon, Apr 29, 2019 at 09:22:12AM -0600, Alex Williamson wrote:
[...]

Quoted 11 lines

Quoted 10 lines

Quoted 6 lines

What's a good 4.0.1 strategy to resolve this? Re-instate KVM irqchip as the Q35 default? I can't see that simply switching to current QEMU handling is a viable option for performance? What about 4.1? We could certainly improve EOI support in QEMU, there's essentially no support currently, but it seems like an uphill battle for an iothread based userspace ioapic to ever compare to KVM handling? Thanks,

irqchip=split and irqchip=kernel aren't guest ABI compatible, are they? That would make it impossible to fix this in pc-q35-4.0 for a 4.0.1 update.

Quoted 1 line

I suppose it would require a pc-q35-4.0.1 machine type :-\ Thanks,

I wonder if it's possible to untangle this and make the irqchip option stop affecting guest ABI on 4.1+ machine-types? This way QEMU could choose smarter defaults in the future without the compatibility code hassle.

Quoted 4 lines

I wonder if it's possible to untangle this and make the irqchip option stop affecting guest ABI on 4.1+ machine-types? This way QEMU could choose smarter defaults in the future without the compatibility code hassle.

Hi, Eduardo,

Do you mean to enable IOMMU IR for kernel-irqchip=on? If so, I would say it's not trivial... The major issue is that we probably need to explicitly kick QEMU for every kernel IOAPIC setups since QEMU is the only one who knows everything about interrupt remapping, while KVM don't even have such a mechanism so far.

Quoted 11 lines · Peter Xu

Quoted 4 lines

I wonder if it's possible to untangle this and make the irqchip option stop affecting guest ABI on 4.1+ machine-types? This way QEMU could choose smarter defaults in the future without the compatibility code hassle.

Hi, Eduardo,

Do you mean to enable IOMMU IR for kernel-irqchip=on? If so, I would say it's not trivial... The major issue is that we probably need to explicitly kick QEMU for every kernel IOAPIC setups since QEMU is the only one who knows everything about interrupt remapping, while KVM don't even have such a mechanism so far.

Right, it's not easy and it would be anyway possible only on kernels. There would have to be a mechanism to setup IOAPIC->MSI routes, similar to irqchip=split, and as Peter mentions an MMIO exit on writes to the routing table.

irqchip=split and irqchip=kernel aren't guest ABI compatible, are they?

Signature · 1 line

Eduardo

Quoted 2 lines · Eduardo Habkost

irqchip=split and irqchip=kernel aren't guest ABI compatible, are they?

Can you remind me why they aren't?

Quoted 2 lines · Eduardo Habkost

irqchip=split and irqchip=kernel aren't guest ABI compatible, are they?

Can you remind me why they aren't?

Quoted 24 lines · On Sat, 27 Apr 2019 10:09:51 +0200 Paolo Bonzini <[email protected]> wrote:

Quoted 16 lines · Paolo Bonzini

Quoted 9 lines

Quoted 8 lines

In my testing it looks like KVM advertises supporting the KVM_IRQFD resample feature, but vfio never gets the unmask notification, so the device remains with DisINTx set and no further interrupts are generated. Do we expect KVM's IRQFD with resampler to work in the split IRQ mode? We can certainly hope that "high performance" devices use MSI or MSI/X, but this would be quite a performance regression with split mode if our userspace bypass for INTx goes away. Thanks,

Quoted 3 lines

arch/x86/kvm/lapic.c:kvm_ioapic_send_eoi() dumps to userspace before kvm_ioapic_update_eoi() can handle the irq_ack_notifier_list via kvm_notify_acked_gsi(),

That wouldn't help because kvm_ioapic_update_eoi would not even be able to access vcpu->kvm->arch.vioapic (it's NULL).

Quoted 6 lines

The following untested patch would signal the resamplefd in kvm_ioapic_send_eoi, before requesting the exit to userspace. However I am not sure how QEMU sets up the VFIO eventfds: if I understand correctly, when VFIO writes again to the irq eventfd, the interrupt request would not reach the userspace IOAPIC, but only the in-kernel LAPIC. That would be incorrect, and if my understanding is correct we need to trigger resampling from hw/intc/ioapic.c.

Quoted 7 lines

Actually it's worse: because you're bypassing IOAPIC when raising the irq, the IOAPIC's remote_irr for example will not be set. So split irqchip currently must disable the intx fast path completely.

I guess we could also reimplement irqfd and resamplefd in the userspace IOAPIC, and run the listener in a separate thread (using "-object iothread" on the command line and AioContext in the code).

This sounds like a performance regression vs KVM irqchip any way we slice it. Was this change a mistake? Without KVM support, the universal support in QEMU kicks in, where device mmaps are disabled when an INTx occurs, forcing trapped access to the device, and we assume that the next access is in response to an interrupt and trigger our own internal EOI and re-enable mmaps. A timer acts as a catch-all. Needless to say, this is functional but not fast. It would be a massive performance regression for devices depending on INTx and previously using the KVM bypass to switch to this. INTx is largely considered a legacy interrupt, so non-x86 archs don't encounter it as often, S390 even explicitly disables INTx support. ARM and POWER likely just don't see a lot of these devices, but nearly all devices (except SR-IOV VFs) on x86 expect an INTx fallback mode and some drivers may run the device in INTx for compatibility. This split irqchip change was likely fine for "enterprise" users concerned only with modern high speed devices, but very much not for device assignment used for compatibility use cases or commodity hardware users.

What's a good 4.0.1 strategy to resolve this? Re-instate KVM irqchip as the Q35 default? I can't see that simply switching to current QEMU handling is a viable option for performance? What about 4.1? We could certainly improve EOI support in QEMU, there's essentially no support currently, but it seems like an uphill battle for an iothread based userspace ioapic to ever compare to KVM handling? Thanks,

Poking at this a bit, we can add kvm_irqchip_is_split() to the set of things we test for in hw/vfio/pci.c:vfio_intx_enable_kvm() to avoid the KVM INTx bypass when using split IRQ chip.

The only way I can get the GPU/Windows configuration usable is to assert the IRQ, immediately de-assert, and unmask the device all from vfio_intx_interrupt(). An interrupt intensive graphics benchmark runs at ~80% of KVM irqchip with about 10% more CPU load with this experiment (but it actually runs!).

Any other insights appreciated, and I really would like to understand what we've gained with split irqchip and whether it's worth this.

Quoted 3 lines · Alex Williamson

Poking at this a bit, we can add kvm_irqchip_is_split() to the set of things we test for in hw/vfio/pci.c:vfio_intx_enable_kvm() to avoid the KVM INTx bypass when using split IRQ chip.

Yes, this should be enough.

Quoted 5 lines

The only way I can get the GPU/Windows configuration usable is to assert the IRQ, immediately de-assert, and unmask the device all from vfio_intx_interrupt(). An interrupt intensive graphics benchmark runs at ~80% of KVM irqchip with about 10% more CPU load with this experiment (but it actually runs!).

Nice. If you can do it directly from hw/vfio there may be no need to do more changes to the IOAPIC, and least not immediately. But that is not a good emulation of INTX, isn't it? IIUC, it relies on the level-triggered interrupt never being masked in the IOAPIC.

Quoted 2 lines

Any other insights appreciated, and I really would like to understand what we've gained with split irqchip and whether it's worth this.

We've gained guest interrupt remapping support, we are not relying on newer kernel versions, and the attack surface from the guest to the hypervisor is smaller.

For old versions of QEMU: we used machine compat properties.

For old kernels (<4.4): if user didn't specify split kernel irqchip, we'll take it only as the first priority if it's supported by the kernel; otherwise, we will continue with complete kernel irqchip.

Both of these parameters should be good to have (split irqchip gains more security, while IR gets it too but even more, like x2apic). So let's try to make them as default if capable.

Quoted 6 lines · Peter Xu

For old versions of QEMU: we used machine compat properties.

For old kernels (<4.4): if user didn't specify split kernel irqchip, we'll take it only as the first priority if it's supported by the kernel; otherwise, we will continue with complete kernel irqchip.

Quoted 3 lines

Both of these parameters should be good to have (split irqchip gains more security, while IR gets it too but even more, like x2apic). So let's try to make them as default if capable.

This is not correct anymore, but the commit message in patch 1 is correct, so

Acked-by Paolo Bonzini <[email protected]>