kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table.
@ 2025-05-08 20:30 David Woodhouse
  2025-05-12  9:29 ` Paul Durrant
  2025-06-24 19:38 ` Sean Christopherson
  0 siblings, 2 replies; 5+ messages in thread
From: David Woodhouse @ 2025-05-08 20:30 UTC (permalink / raw)
  To: kvm, Sean Christopherson, Orlov, Ivan
  Cc: Paul Durrant, Paolo Bonzini, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]

From: David Woodhouse <dwmw@amazon.co.uk>

To avoid imposing an ordering constraint on userspace, allow 'invalid'
event channel targets to be configured in the IRQ routing table.

This is the same as accepting interrupts targeted at vCPUs which don't
exist yet, which is already the case for both Xen event channels *and*
for MSIs (which don't do any filtering of permitted APIC ID targets at
all).

If userspace actually *triggers* an IRQ with an invalid target, that
will fail cleanly, as kvm_xen_set_evtchn_fast() also does the same range
check.

If KVM enforced that the IRQ target must be valid at the time it is
*configured*, that would force userspace to create all vCPUs and do
various other parts of setup (in this case, setting the Xen long_mode)
before restoring the IRQ table.

Cc: stable@vger.kernel.org
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/kvm/xen.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 38b33cdd4232..2a593db2ea3f 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -1970,8 +1970,18 @@ int kvm_xen_setup_evtchn(struct kvm *kvm,
 {
 	struct kvm_vcpu *vcpu;
 
-	if (ue->u.xen_evtchn.port >= max_evtchn_port(kvm))
-		return -EINVAL;
+	/*
+	 * No check for being within range of max_evtchn_port() here.
+	 * Userspace can configure what ever targets it likes; they
+	 * just won't be delivered if/while they're invalid. Just like
+	 * userspace can configure MSIs which target non-existent APICs.
+	 * This means that on Live Migration and Live Update, the IRQ
+	 * routing table and be restored *independently* of other things
+	 * like creating vCPUs without imposing an ordering dependency on
+	 * userspace. In this particular case, the problematic ordering
+	 * would be with setting the Xen 'long mode' flag which changes
+	 * max_evtchn_port() to allow 4096 instead of 1024 event channels.
+	 */
 
 	/* We only support 2 level event channels for now */
 	if (ue->u.xen_evtchn.priority != KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL)
-- 
2.49.0



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table.
  2025-05-08 20:30 KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table David Woodhouse
@ 2025-05-12  9:29 ` Paul Durrant
  2025-06-23 16:44   ` David Woodhouse
  2025-06-24 19:38 ` Sean Christopherson
  1 sibling, 1 reply; 5+ messages in thread
From: Paul Durrant @ 2025-05-12  9:29 UTC (permalink / raw)
  To: David Woodhouse, kvm, Sean Christopherson, Orlov, Ivan
  Cc: Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, x86, H. Peter Anvin, linux-kernel

On 08/05/2025 21:30, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> To avoid imposing an ordering constraint on userspace, allow 'invalid'
> event channel targets to be configured in the IRQ routing table.
> 
> This is the same as accepting interrupts targeted at vCPUs which don't
> exist yet, which is already the case for both Xen event channels *and*
> for MSIs (which don't do any filtering of permitted APIC ID targets at
> all).
> 
> If userspace actually *triggers* an IRQ with an invalid target, that
> will fail cleanly, as kvm_xen_set_evtchn_fast() also does the same range
> check.
> 
> If KVM enforced that the IRQ target must be valid at the time it is
> *configured*, that would force userspace to create all vCPUs and do
> various other parts of setup (in this case, setting the Xen long_mode)
> before restoring the IRQ table.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
>   arch/x86/kvm/xen.c | 14 ++++++++++++--
>   1 file changed, 12 insertions(+), 2 deletions(-)
> 

Reviewed-by: Paul Durrant <paul@xen.org>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table.
  2025-05-12  9:29 ` Paul Durrant
@ 2025-06-23 16:44   ` David Woodhouse
  2025-06-23 16:48     ` Sean Christopherson
  0 siblings, 1 reply; 5+ messages in thread
From: David Woodhouse @ 2025-06-23 16:44 UTC (permalink / raw)
  To: paul, kvm, Sean Christopherson, Orlov, Ivan
  Cc: Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, x86, H. Peter Anvin, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

On Mon, 2025-05-12 at 10:29 +0100, Paul Durrant wrote:
> On 08/05/2025 21:30, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> > 
> > To avoid imposing an ordering constraint on userspace, allow 'invalid'
> > event channel targets to be configured in the IRQ routing table.
> > 
> > This is the same as accepting interrupts targeted at vCPUs which don't
> > exist yet, which is already the case for both Xen event channels *and*
> > for MSIs (which don't do any filtering of permitted APIC ID targets at
> > all).
> > 
> > If userspace actually *triggers* an IRQ with an invalid target, that
> > will fail cleanly, as kvm_xen_set_evtchn_fast() also does the same range
> > check.
> > 
> > If KVM enforced that the IRQ target must be valid at the time it is
> > *configured*, that would force userspace to create all vCPUs and do
> > various other parts of setup (in this case, setting the Xen long_mode)
> > before restoring the IRQ table.
> > 
> > Cc: stable@vger.kernel.org
> > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> > ---
> >   arch/x86/kvm/xen.c | 14 ++++++++++++--
> >   1 file changed, 12 insertions(+), 2 deletions(-)
> > 
> 
> Reviewed-by: Paul Durrant <paul@xen.org>

Ping?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table.
  2025-06-23 16:44   ` David Woodhouse
@ 2025-06-23 16:48     ` Sean Christopherson
  0 siblings, 0 replies; 5+ messages in thread
From: Sean Christopherson @ 2025-06-23 16:48 UTC (permalink / raw)
  To: David Woodhouse
  Cc: paul, kvm, Ivan Orlov, Paolo Bonzini, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
	linux-kernel

On Mon, Jun 23, 2025, David Woodhouse wrote:
> On Mon, 2025-05-12 at 10:29 +0100, Paul Durrant wrote:
> > On 08/05/2025 21:30, David Woodhouse wrote:
> > > From: David Woodhouse <dwmw@amazon.co.uk>
> > > 
> > > To avoid imposing an ordering constraint on userspace, allow 'invalid'
> > > event channel targets to be configured in the IRQ routing table.
> > > 
> > > This is the same as accepting interrupts targeted at vCPUs which don't
> > > exist yet, which is already the case for both Xen event channels *and*
> > > for MSIs (which don't do any filtering of permitted APIC ID targets at
> > > all).
> > > 
> > > If userspace actually *triggers* an IRQ with an invalid target, that
> > > will fail cleanly, as kvm_xen_set_evtchn_fast() also does the same range
> > > check.
> > > 
> > > If KVM enforced that the IRQ target must be valid at the time it is
> > > *configured*, that would force userspace to create all vCPUs and do
> > > various other parts of setup (in this case, setting the Xen long_mode)
> > > before restoring the IRQ table.
> > > 
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> > > ---
> > >   arch/x86/kvm/xen.c | 14 ++++++++++++--
> > >   1 file changed, 12 insertions(+), 2 deletions(-)
> > > 
> > 
> > Reviewed-by: Paul Durrant <paul@xen.org>
> 
> Ping?

Almost there :-)  I've got it applied (for 6.16), just need to run my generic
test stuff before making it "official".

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table.
  2025-05-08 20:30 KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table David Woodhouse
  2025-05-12  9:29 ` Paul Durrant
@ 2025-06-24 19:38 ` Sean Christopherson
  1 sibling, 0 replies; 5+ messages in thread
From: Sean Christopherson @ 2025-06-24 19:38 UTC (permalink / raw)
  To: Sean Christopherson, kvm, Ivan Orlov, David Woodhouse
  Cc: Paul Durrant, Paolo Bonzini, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, linux-kernel

On Thu, 08 May 2025 13:30:12 -0700, David Woodhouse wrote:
> To avoid imposing an ordering constraint on userspace, allow 'invalid'
> event channel targets to be configured in the IRQ routing table.
> 
> This is the same as accepting interrupts targeted at vCPUs which don't
> exist yet, which is already the case for both Xen event channels *and*
> for MSIs (which don't do any filtering of permitted APIC ID targets at
> all).
> 
> [...]

Applied to kvm-x86 fixes, thanks!

[1/1] KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table.
      https://github.com/kvm-x86/linux/commit/a7f4dff21fd7

--
https://github.com/kvm-x86/kvm-unit-tests/tree/next

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2025-06-24 19:38 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-05-08 20:30 KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table David Woodhouse
2025-05-12  9:29 ` Paul Durrant
2025-06-23 16:44   ` David Woodhouse
2025-06-23 16:48     ` Sean Christopherson
2025-06-24 19:38 ` Sean Christopherson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).