linux-kernel - RE: [PATCH 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 2 Mar 2018 07:08:51 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Alex Williamson <alex.williamson@...hat.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
        "peterx@...hat.com" <peterx@...hat.com>,
        "eric.auger@...hat.com" <eric.auger@...hat.com>,
        "aik@...abs.ru" <aik@...abs.ru>
Subject: RE: [PATCH 0/3] vfio/pci: ioeventfd support

> From: Alex Williamson
> Sent: Thursday, March 1, 2018 4:15 AM
> 
> 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.
> 

it's a nice feature! A curious question. Is it possible for mdev driver
to directly create ioeventfd on specified offset? Currently ioeventfd
requires quirks in Qemu, which must know the device detail to
create ioeventfd and then connect vfio and kvm together. However
mdev instance is more software defined thus I'm not sure whether 
asking Qemu to catch up quirk with underlying software logic could
be overwhelmed. Also in case of vendor driver emulating mdev
with same DID/VID as a real device, it might be difficult for Qemu
to figure out whether a vfio device is a real one or mdev one to
apply a mdev specific quirk. On the other hand, since vendor
driver knows all the logic constructing mdev, it would be more
convenient allowing vendor driver to directly create/destroy
ioeventfd on its demand?

Thanks
Kevin