linux-kernel - Re: VFIO MSIX Query

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] [day] [month] [year] [list]

Date:	Wed, 4 May 2016 02:12:30 +0000
From:	"Saxena, Nitin" <Nitin.Saxena@...iumnetworks.com>
To:	Alex Williamson <alex.williamson@...hat.com>
CC:	Nitin Saxena <nitin.lnx@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: VFIO MSIX Query

Got it. Thanks Alex. I may have future queries as well on this. Will get back to you.

Thanks,
Nitin

> On 04-May-2016, at 01:33, Alex Williamson <alex.williamson@...hat.com> wrote:
> 
> Hi,
> 
> On Tue, 3 May 2016 23:56:38 +0530
> Nitin Saxena <nitin.lnx@...il.com> wrote:
> 
>> Hi,
>> 
>> I am a newbie to VFIO framework and trying to use it for MSIX interrupt
>> handling in my userspace application. My userspace application is like
>> intel's dpdk.
>> 
>> My query is why vfio kernel code does not support msix masking/ unmasking
>> i.e VFIO_SET_ACTION_TRIGGER is not implemented in kernel vfio code for MSIX
>> but its present for legacy INTX?
> 
> I think you mean VFIO_IRQ_SET_ACTION_MASK and
> VFIO_IRQ_SET_ACTION_UNMASK are not implemented for MSI/X,
> VFIO_IRQ_SET_ACTION_TRIGGER is the only one that is implemented.  It
> mostly comes down to it hasn't been needed.  We would just need to
> verify that disable_irq() and enable_irq() do the right thing and
> enable the features through the existing VFIO API.  The reason we have
> these for INTx is that INTx is level triggered and we must mask the
> interrupt on the host while it's serviced by the user because the
> interrupt will continue to assert and we have no service guarantees
> from the user.  MSI/X is of course edge triggered, so doesn't have this
> problem.  The device would need to continue to re-assert the
> interrupt.  In cases like a QEMU user, we might want to continue to
> receive guest masked interrupts to QEMU for emulating the pending bits
> array, so even if we had VFIO masking support for these interrupts, QEMU
> probably would not use it.  If MSI/X masking is useful for you vs simply
> ignoring the eventfd, patches welcome.
> 
>> Another question since MSIX interrupt masking is absent in kernel who is
>> supposed to mask/unmask msix interrupt? does userspace needs to mask/unmask
>> interrupt after getting notified by eventfd. Is there any usecase where
>> MSIX handling is done via VFIO framework?
> 
> MSI/X is edge triggered and VFIO does not set the AUTOMASKED flag on
> them, so there is simply no masking of them at all aside from fully
> disabling them.  QEMU has full support for MSI/X through VFIO that you
> can use for reference.  Thanks,
> 
> Alex