All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org, aik@ozlabs.ru, benh@kernel.crashing.org,
	bsd@redhat.com, linux-kernel@vger.kernel.org, mst@redhat.com
Subject: Re: [RFC PATCH 3/3] kvm: Add VFIO device for handling IOMMU cache coherency
Date: Sun, 29 Sep 2013 17:44:09 +0300	[thread overview]
Message-ID: <20130929144409.GD2909@redhat.com> (raw)
In-Reply-To: <1380462748.2674.57.camel@ul30vt.home>

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.

  reply	other threads:[~2013-09-29 14:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-12 21:22 [RFC PATCH 0/3] kvm/vfio: Manage KVM IOMMU coherency with virtual VFIO device Alex Williamson
2013-09-12 21:23 ` [RFC PATCH 1/3] kvm: Destroy & free KVM devices on release Alex Williamson
2013-09-12 21:23 ` [RFC PATCH 2/3] vfio: Add check extension interface to external user support Alex Williamson
2013-09-12 21:23 ` [RFC PATCH 3/3] kvm: Add VFIO device for handling IOMMU cache coherency Alex Williamson
2013-09-13  8:49   ` Alexey Kardashevskiy
2013-09-13 16:25     ` Alex Williamson
2013-09-15 12:40       ` Alexey Kardashevskiy
2013-09-25 20:19         ` Alex Williamson
2013-09-26  4:31           ` Alexey Kardashevskiy
2013-09-13 12:39   ` Michael S. Tsirkin
2013-09-13 14:13     ` Alex Williamson
2013-09-13 14:52       ` Michael S. Tsirkin
2013-09-13 15:29         ` Alex Williamson
2013-09-29 13:16   ` Gleb Natapov
2013-09-29 13:52     ` Alex Williamson
2013-09-29 14:44       ` Gleb Natapov [this message]
2013-09-29 15:55         ` Alex Williamson
2013-09-30 13:23           ` Gleb Natapov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130929144409.GD2909@redhat.com \
    --to=gleb@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=benh@kernel.crashing.org \
    --cc=bsd@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.