Hi Paolo and Dmytro, > -----Original Message----- > From: Paolo Bonzini <pbonzini@xxxxxxxxxx> > Sent: Wednesday, August 10, 2022 11:48 PM > To: Dmytro Maluka <dmy@xxxxxxxxxxxx>; Marc Zyngier > <maz@xxxxxxxxxx>; eric.auger@xxxxxxxxxx > Cc: Dong, Eddie <eddie.dong@xxxxxxxxx>; Christopherson,, Sean > <seanjc@xxxxxxxxxx>; kvm@xxxxxxxxxxxxxxx; Thomas Gleixner > <tglx@xxxxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; Borislav > Petkov <bp@xxxxxxxxx>; Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>; > x86@xxxxxxxxxx; H. Peter Anvin <hpa@xxxxxxxxx>; linux- > kernel@xxxxxxxxxxxxxxx; Alex Williamson <alex.williamson@xxxxxxxxxx>; > Liu, Rong L <rong.l.liu@xxxxxxxxx>; Zhenyu Wang > <zhenyuw@xxxxxxxxxxxxxxx>; Tomasz Nowicki <tn@xxxxxxxxxxxx>; > Grzegorz Jaszczyk <jaz@xxxxxxxxxxxx>; upstream@xxxxxxxxxxxx; > Dmitry Torokhov <dtor@xxxxxxxxxx> > Subject: Re: [PATCH v2 0/5] KVM: Fix oneshot interrupts forwarding > > On 8/10/22 19:02, Dmytro Maluka wrote: > > 1. If vEOI happens for a masked vIRQ, notify resamplefd as usual, > > but also remember this vIRQ as, let's call it, "pending oneshot". > > This is the part always confuses me. In x86 case, for level triggered interrupt, even if it is not oneshot, there is still "unmask" and the unmask happens in the same sequence as in oneshot interrupt, just timing is different. So are you going to differentiate oneshot from "normal" level triggered interrupt or not? And there is any situation that vEOI happens for an unmasked vIRQ? > > 2. A new physical IRQ is immediately generated, so the vIRQ is > > properly set as pending. > > I am not sure this is always the case. For example, a device may not raise a new interrupt until it is notified that "done reading" - by device driver writing to a register or something when device driver finishes reading data. So how do you handle this situation? > > 3. After the vIRQ is unmasked by the guest, check and find out that > > it is not just pending but also "pending oneshot", so don't > > deliver it to a vCPU. Instead, immediately notify resamplefd once > > again. > > Does this mean the change of vfio code also? That seems the case: vfio seems keeping its own internal "state" whether the irq is enabled or not. Thanks, Rong > > In other words, don't avoid extra physical interrupts in the host > > (rather, use those extra interrupts for properly updating the pending > > state of the vIRQ) but avoid propagating those extra interrupts to the > > guest. > > > > Does this sound reasonable to you? > > Yeah, this makes sense and it lets the resamplefd set the "pending" > status in the vGIC. It still has the issue that the interrupt can > remain pending in the guest for longer than it's pending on the host, > but that can't be fixed? > > Paolo
