linux-kernel - Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ 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: <1434135815.4927.308.camel@redhat.com>
Date:	Fri, 12 Jun 2015 13:03:35 -0600
From:	Alex Williamson <alex.williamson@...hat.com>
To:	Avi Kivity <avi.kivity@...il.com>
Cc:	"Wu, Feng" <feng.wu@...el.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>,
	"mtosatti@...hat.com" <mtosatti@...hat.com>,
	"eric.auger@...aro.org" <eric.auger@...aro.org>
Subject: Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding

On Fri, 2015-06-12 at 21:48 +0300, Avi Kivity wrote:
> On 06/12/2015 06:41 PM, Alex Williamson wrote:
> > On Fri, 2015-06-12 at 00:23 +0000, Wu, Feng wrote:
> >>> -----Original Message-----
> >>> From: Avi Kivity [mailto:avi.kivity@...il.com]
> >>> Sent: Friday, June 12, 2015 3:59 AM
> >>> To: Wu, Feng; kvm@...r.kernel.org; linux-kernel@...r.kernel.org
> >>> Cc: pbonzini@...hat.com; mtosatti@...hat.com;
> >>> alex.williamson@...hat.com; eric.auger@...aro.org
> >>> Subject: Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding
> >>>
> >>> On 06/11/2015 01:51 PM, Feng Wu wrote:
> >>>> From: Eric Auger <eric.auger@...aro.org>
> >>>>
> >>>> This patch adds and documents a new KVM_DEV_VFIO_DEVICE group
> >>>> and 2 device attributes: KVM_DEV_VFIO_DEVICE_FORWARD_IRQ,
> >>>> KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ. The purpose is to be able
> >>>> to set a VFIO device IRQ as forwarded or not forwarded.
> >>>> the command takes as argument a handle to a new struct named
> >>>> kvm_vfio_dev_irq.
> >>> Is there no way to do this automatically?  After all, vfio knows that a
> >>> device interrupt is forwarded to some eventfd, and kvm knows that some
> >>> eventfd is forwarded to a guest interrupt.  If they compare notes
> >>> through a central registry, they can figure out that the interrupt needs
> >>> to be forwarded.
> >> Oh, just like Eric mentioned in his reply, this description is out of context of
> >> this series, I will remove them in the next version.
> >
> > I suspect Avi's question was more general.  While forward/unforward is
> > out of context for this series, it's very similar in nature to
> > enabling/disabling posted interrupts.  So I think the question remains
> > whether we really need userspace to participate in creating this
> > shortcut or if kvm and vfio can some how orchestrate figuring it out
> > automatically.
> >
> > Personally I don't know how we could do it automatically.  We've always
> > relied on userspace to independently setup vfio and kvm such that
> > neither have any idea that the other is there and update each side
> > independently when anything changes.  So it seems consistent to continue
> > that here.  It doesn't seem like there's much to gain performance-wise
> > either, updates should be a relatively rare event I'd expect.
> >
> > There's really no metadata associated with an eventfd, so "comparing
> > notes" automatically might imply some central registration entity.  That
> > immediately sounds like a much more complex solution, but maybe Avi has
> > some ideas to manage it.  Thanks,
> >
> 
> The idea is to have a central registry maintained by a posted interrupts 
> manager.  Both vfio and kvm pass the filp (along with extra information) 
> to the posted interrupts manager, which, when it detects a filp match, 
> tells each of them what to do.
> 
> The advantages are:
> - old userspace gains the optimization without change
> - a userspace API is more expensive to maintain than internal kernel 
> interfaces (CVEs, documentation, maintaining backwards compatibility)
> - if you can do it without a new interface, this indicates that all the 
> information in the new interface is redundant.  That means you have to 
> check it for consistency with the existing information, so it's extra 
> work (likely, it's exactly what the posted interrupt manager would be 
> doing anyway).

Yep, those all sound like good things and I believe that's similar in
design to the way we had originally discussed this interaction at
LPC/KVM Forum several years ago.  I'd be in favor of that approach.
Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/