linux-kernel - RE: [PATCH v2 0/5] KVM: Fix oneshot interrupts forwarding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MW3PR11MB4554AAFB43FA6B0B612150D9C7649@MW3PR11MB4554.namprd11.prod.outlook.com>
Date:   Thu, 11 Aug 2022 22:40:47 +0000
From:   "Liu, Rong L" <rong.l.liu@...el.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Dmytro Maluka <dmy@...ihalf.com>,
        Marc Zyngier <maz@...nel.org>,
        "eric.auger@...hat.com" <eric.auger@...hat.com>
CC:     "Dong, Eddie" <eddie.dong@...el.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "Borislav Petkov" <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Alex Williamson" <alex.williamson@...hat.com>,
        Zhenyu Wang <zhenyuw@...ux.intel.com>,
        Tomasz Nowicki <tn@...ihalf.com>,
        "Grzegorz Jaszczyk" <jaz@...ihalf.com>,
        "upstream@...ihalf.com" <upstream@...ihalf.com>,
        Dmitry Torokhov <dtor@...gle.com>
Subject: RE: [PATCH v2 0/5] KVM: Fix oneshot interrupts forwarding

Hi Paolo and Dmytro,

> -----Original Message-----
> From: Paolo Bonzini <pbonzini@...hat.com>
> Sent: Wednesday, August 10, 2022 11:48 PM
> To: Dmytro Maluka <dmy@...ihalf.com>; Marc Zyngier
> <maz@...nel.org>; eric.auger@...hat.com
> Cc: Dong, Eddie <eddie.dong@...el.com>; Christopherson,, Sean
> <seanjc@...gle.com>; kvm@...r.kernel.org; Thomas Gleixner
> <tglx@...utronix.de>; Ingo Molnar <mingo@...hat.com>; Borislav
> Petkov <bp@...en8.de>; Dave Hansen <dave.hansen@...ux.intel.com>;
> x86@...nel.org; H. Peter Anvin <hpa@...or.com>; linux-
> kernel@...r.kernel.org; Alex Williamson <alex.williamson@...hat.com>;
> Liu, Rong L <rong.l.liu@...el.com>; Zhenyu Wang
> <zhenyuw@...ux.intel.com>; Tomasz Nowicki <tn@...ihalf.com>;
> Grzegorz Jaszczyk <jaz@...ihalf.com>; upstream@...ihalf.com;
> Dmitry Torokhov <dtor@...gle.com>
> 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