linux-kernel - Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <5613DE26.1090202@cloudius-systems.com>
Date:	Tue, 6 Oct 2015 17:43:50 +0300
From:	Vlad Zolotarov <vladz@...udius-systems.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>,
	Avi Kivity <avi@...lladb.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org,
	hjk@...sjkoch.de, corbet@....net, bruce.richardson@...el.com,
	avi@...udius-systems.com, gleb@...udius-systems.com,
	stephen@...workplumber.org, alexander.duyck@...il.com
Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support



On 10/06/15 17:38, Michael S. Tsirkin wrote:
> On Mon, Oct 05, 2015 at 01:20:11PM +0300, Avi Kivity wrote:
>> On 10/05/2015 12:49 PM, Greg KH wrote:
>>> On Mon, Oct 05, 2015 at 11:28:03AM +0300, Avi Kivity wrote:
>>>> Of course it has to be documented, but this just follows vfio.
>>>>
>>>> Eventfd is a natural enough representation of an interrupt; both kvm and
>>>> vfio use it, and are also able to share the eventfd, allowing a vfio
>>>> interrupt to generate a kvm interrupt, without userspace intervention, and
>>>> one day without even kernel intervention.
>>> That's nice and wonderful, but it's not how UIO works today, so this is
>>> now going to be a mix and match type interface, with no justification so
>>> far as to why to create this new api and exactly how this is all going
>>> to be used from userspace.
>> The intended user is dpdk (http://dpdk.org), which is a family of userspace
>> networking drivers for high performance networking applications.
>>
>> The natural device driver for dpdk is vfio, which both provides memory
>> protection and exposes msi/msix interrupts.  However, in many cases vfio
>> cannot be used, either due to the lack of an iommu (for example, in
>> virtualized environments) or out of a desire to avoid the iommus performance
>> impact.
>>
>> The challenge in exposing msix interrupts to user space is that there are
>> many of them, so you can't simply poll the device fd.  If you do, how do you
>> know which interrupt was triggered?  The solution that vfio adopted was to
>> associate each interrupt with an eventfd, allowing it to be individually
>> polled.  Since you can pass an eventfd with SCM_RIGHTS, and since kvm can
>> trigger guest interrupts using an eventfd, the solution is very flexible.
>>
>>> Example code would be even better...
>>>
>>>
>>
>> This is the vfio dpdk interface code:
>>
>> http://dpdk.org/browse/dpdk/tree/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
>>
>> basically, the equivalent uio msix code would be very similar if uio adopts
>> a similar interface:
>>
>> http://dpdk.org/browse/dpdk/tree/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
>>
>> (current code lacks msi/msix support, of course).
> So you really want a driver that behaves exactly like vfio.
> Which immediately begs a question: why not extend vfio
> to cover your usecase.

The only "like VFIO" behavior we implement here is binding the MSI-X 
interrupt notification to eventfd descriptor. This doesn't justifies the 
hassle of implementing IOMMU-less VFIO mode.



>

--
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/