lkml.org 
[lkml]   [2013]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 3/3] kvm: Add VFIO device for handling IOMMU cache coherency
    On Sun, Sep 29, 2013 at 07:52:28AM -0600, Alex Williamson wrote:
    > On Sun, 2013-09-29 at 16:16 +0300, Gleb Natapov wrote:
    > > On Thu, Sep 12, 2013 at 03:23:15PM -0600, Alex Williamson wrote:
    > > > So far we've succeeded at making KVM and VFIO mostly unaware of each
    > > > other, but there's any important point where that breaks down. Intel
    > > > VT-d hardware may or may not support snoop control. When snoop
    > > > control is available, intel-iommu promotes No-Snoop transactions on
    > > > PCIe to be cache coherent. That allows KVM to handle things like the
    > > > x86 WBINVD opcode as a nop. When the hardware does not support this,
    > > > KVM must implement a hardware visible WBINVD for the guest.
    > > >
    > > > We could simply let userspace tell KVM how to handle WBINVD, but it's
    > > > privileged for a reason. Allowing an arbitrary user to enable
    > > > physical WBINVD gives them a more access to the hardware. Previously,
    > > > this has only been enabled for guests supporting legacy PCI device
    > > > assignment. In such cases it's necessary for proper guest execution.
    > > > We therefore create a new KVM-VFIO virtual device. The user can add
    > > > and remove VFIO groups to this device via file descriptors. KVM
    > > > makes use of the VFIO external user interface to validate that the
    > > > user has access to physical hardware and gets the coherency state of
    > > > the IOMMU from VFIO. This provides equivalent functionality to
    > > > legacy KVM assignment, while keeping (nearly) all the bits isolated.
    > > >
    > > Looks good overall to me, one things though: to use legacy device
    > > assignment one needs root permission, so only root user can enable
    > > WBINVD emulation.
    >
    > That's not entirely accurate, legacy device assignment can be used by a
    > non-root user, libvirt does this all the time. The part that requires
    > root access is opening the pci-sysfs config file, the rest can be
    > managed via file permissions on the remaining sysfs files.
    >
    So how libvirt manages to do that as non-root user if pci-sysfs config
    file needs root permission. I didn't mean to say that legacy code
    checks for root explicitly, what I meant is that at some point root
    permission is needed.

    > > Who does this permission checking here? Is only root
    > > allowed to create non coherent group with vfio?
    >
    > With vfio the user is granted permission by giving them access to the
    > vfio group file (/dev/vfio/$GROUP) and binding all the devices in the
    > group to vfio. That enables the user to create a container (~iommu
    > domain) with the group attached to it. Only then will the vfio external
    > user interface provide a reference to the group and enable this wbinvd
    > support. So, wbinvd emulation should only be available to a user that
    > "own" a vfio group and has it configured for use with this interface.
    What is the default permission of /dev/vfio/$GROUP?

    --
    Gleb.


    \
     
     \ /
      Last update: 2013-09-29 17:01    [W:9.129 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site