linux-kernel - Re: [PATCH v2 0/3] vfio/pci: ioeventfd 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] [day] [month] [year] [list]

Message-ID: <28b02805-fa03-7f7c-b603-fa8985b305aa@ozlabs.ru>
Date:   Mon, 19 Mar 2018 20:09:04 +1100
From:   Alexey Kardashevskiy <aik@...abs.ru>
To:     Alex Williamson <alex.williamson@...hat.com>, kvm@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, qemu-devel@...gnu.org,
        peterx@...hat.com, eric.auger@...hat.com
Subject: Re: [PATCH v2 0/3] vfio/pci: ioeventfd support

On 16/3/18 8:31 am, Alex Williamson wrote:
> A vfio ioeventfd will perform the pre-specified device write on
> triggering of an eventfd.  When coupled with KVM ioeventfds, this
> feature allows a VM to trap a device page for virtualization, while
> also registering targeted ioeventfds to maintain performance of high
> frequency register writes within the trapped range.  Much like the
> existing interrupt eventfd/irqfd coupling, such writes can be handled
> entirely in the host kernel.
> 
> The new VFIO device ioctl may be supported by any vfio bus driver,
> including mdev drivers, but the implementation here only enables
> vfio-pci.  This is intended as an acceleration path, bus drivers
> may choose which regions to support and userspace should always
> intend to fall back to non-accelerated handling when unavailable.
> 
> v1->v2:
>  * Peter & Eric Sign-offs on 1/3
>  * mutex_destroy() in 3/3
>  * Slight enhancement to uapi description
>  * sparse clean - Sparse didn't like that we dropped the __iomem
>    address space when calling iowriteXX, re-adding it via the opaque
>    and data pointers of the virq was crude, and that was not a 32-bit
>    friendly soluion anyway, so add the iomem address to our ioeventfd
>    struct, pass that, and use a more simple, common handler.
> 
> RFC->v1:
>  * An arbitrary limit is added for the number of ioeventfds supported
>    per device.  The intention is to set this high enough to allow any
>    reasonable use case, but limit malicious user behavior.
>  * Split patches, including adding a patch for endian neutral io reads
>    and writes.  This should be a nop for little-endian and avoid
>    redundant swap on big-endian, and hopefully resolves Alexey's
>    comments regarding the endian nature of this interface.
>  * Rebase to v4.16-rc3
> 
> Thanks,
> Alex
> 
> ---
> 
> Alex Williamson (3):
>       vfio/pci: Pull BAR mapping setup from read-write path
>       vfio/pci: Use endian neutral helpers
>       vfio/pci: Add ioeventfd support
> 
> 
>  drivers/vfio/pci/vfio_pci.c         |   35 +++++++
>  drivers/vfio/pci/vfio_pci_private.h |   19 ++++
>  drivers/vfio/pci/vfio_pci_rdwr.c    |  184 +++++++++++++++++++++++++++++++----
>  include/uapi/linux/vfio.h           |   27 +++++
>  4 files changed, 245 insertions(+), 20 deletions(-)
> 


LGTM, I gave it a try to make sure 2/3 does not break and it does not in
all combinations of le/be host <=> le/be guest but I did not try the actual
feature - cannot make up a test quickly...

Reviewed-by: Alexey Kardashevskiy <aik@...abs.ru>


-- 
Alexey