linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: gleb@redhat.com
Cc: aik@ozlabs.ru, linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v2 4/4] kvm: Add VFIO device for handling IOMMU cache coherency
Date: Thu, 03 Oct 2013 14:40:42 -0600	[thread overview]
Message-ID: <1380832842.2673.80.camel@ul30vt.home> (raw)
In-Reply-To: <20131003025134.8850.97617.stgit@bling.home>

On Wed, 2013-10-02 at 20:55 -0600, Alex Williamson wrote:
> So far we've succeeded at making KVM and VFIO mostly unaware of each
> other, but there's an 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 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, for now, assumes the I/O
> is noncoherent.  Eventually we'll add an interface to allow KVM to
> determine the conherency of the domain as noted in the TODO.
> 
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
> 
> v2: Patches 1-3 of v1 series remain the same, not resent
>   - Fix cast warning from (int32_t *)u64 from get_user calls
>   - Add a Kconfig variable to protect kvm_vfio_ops for archs
>     not (yet) building virt/kvm/vfio.c

There might be another option for my particular need of this.  The
device PCIe capability has a bit in the Device Control register that
enables a device to do NoSnoop transactions.  Therefore it seems like by
clearing this bit on the physical device and emulating it as read-only
in the guest, we can prevent the NoSnoop at the device rather than at
the IOMMU.  If we can prevent NoSnoop, then I don't think we need to
worry about things like WBINVD emulation in KVM.  Let me work on this a
bit more before applying.  Thanks,

Alex


  reply	other threads:[~2013-10-03 20:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-01 20:15 [PATCH 0/4] KVM noncoherent DMA registration and VFIO pseudo device Alex Williamson
2013-10-01 20:15 ` [PATCH 1/4] kvm: Destroy & free KVM devices on release Alex Williamson
2013-10-01 20:15 ` [PATCH 2/4] kvm/x86: Convert iommu_flags to iommu_noncoherent Alex Williamson
2013-10-01 20:15 ` [PATCH 3/4] kvm: Create non-coherent DMA registeration Alex Williamson
2013-10-04 10:02   ` Alexey Kardashevskiy
2013-10-04 14:53     ` Alex Williamson
2013-10-01 20:15 ` [PATCH 4/4] kvm: Add VFIO device for handling IOMMU cache coherency Alex Williamson
2013-10-03  2:55   ` [PATCH v2 " Alex Williamson
2013-10-03 20:40     ` Alex Williamson [this message]
2013-10-04 12:24 ` [RFC PATCH] PPC: KVM: vfio kvm device: support spapr tce Alexey Kardashevskiy
2013-10-04 16:05   ` Alex Williamson
2013-10-05  1:52     ` Alexey Kardashevskiy
2013-10-05  3:36       ` Alexey Kardashevskiy

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=1380832842.2673.80.camel@ul30vt.home \
    --to=alex.williamson@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).