Re: [RFC PATCH 18/21] kvm/ioapic: mark gsi-2 used in ioapic routing init

From: David Woodhouse <dwmw2@infradead.org>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>, Paul Durrant <paul@xen.org>,
	Joao Martins <joao.m.martins@oracle.com>,
	Ankur Arora <ankur.a.arora@oracle.com>
Subject: Re: [RFC PATCH 18/21] kvm/ioapic: mark gsi-2 used in ioapic routing init
Date: Tue, 06 Dec 2022 01:21:55 +0000	[thread overview]
Message-ID: <0e0724bf05914b093bcd6f9f8c0e67b4d0938f03.camel@infradead.org> (raw)
In-Reply-To: <691190cd-7c0e-5f30-f5e6-ccf0a84cf3bb@linaro.org>

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

On Mon, 2022-12-05 at 23:25 +0100, Philippe Mathieu-Daudé wrote:
> On 5/12/22 18:31, David Woodhouse wrote:
> > From: Ankur Arora <
> > ankur.a.arora@oracle.com
> > >
> > 
> > GSI-2/IOAPIC pin-2 is treated specially while initing
> > IRQ routing: PIC does not use it at all while the IOAPIC
> > maps virq=0 to pin-2 and does not use GSI-2.
> > (all other GSIs are identity mapped to pins.)
> > 
> > This results in any later code which allocates a virq
> > to be assigned GSI-2. This virq is in-turn used to
> > remap interrupts to HYPERVISOR_CALLBACK_VECTOR (0xf3)
> > to deliver to the guest.
> > 
> > Ordinarily this would be okay, but if the event delivery is
> > via direct injection via KVM_REQ_EVENT (without going
> > through the LAPIC) we see vmentry failure.
> > 
> > This works fine for any other values of GSI.
> > 
> > As a workaround, mark GSI-2 used.
> > 
> > Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
> > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> > ---
> >   accel/kvm/kvm-all.c  | 5 +++++
> >   hw/i386/kvm/ioapic.c | 1 +
> >   include/sysemu/kvm.h | 1 +
> >   3 files changed, 7 insertions(+)
> 
> 
> > diff --git a/hw/i386/kvm/ioapic.c b/hw/i386/kvm/ioapic.c
> > index ee7c8ef68b..5fab0d35c9 100644
> > --- a/hw/i386/kvm/ioapic.c
> > +++ b/hw/i386/kvm/ioapic.c
> > @@ -43,6 +43,7 @@ void kvm_pc_setup_irq_routing(bool pci_enabled)
> >               }
> >           }
> >       }
> 
> Workarounds usually deserve some comment in the code.

Yes, good point. Although I actually think I can kill this off
completely since we no longer attempt the deliver the vector directly
with KVM_REQ_EVENT anyway; the kernel injects it *for* us when it sees
that vcpu_info->evtchn_upcall_pending is set on entry to the guest
vCPU.

> > +    kvm_irqchip_set_gsi(s, 2);
> >       kvm_irqchip_commit_routes(s);
> >   }

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