All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: qemu-devel@nongnu.org, peterx@redhat.com,
	cornelia.huck@de.ibm.com, wexu@redhat.com, vkaplans@redhat.com,
	pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH V4 net-next] vhost_net: device IOTLB support
Date: Fri, 13 Jan 2017 18:30:20 +0200	[thread overview]
Message-ID: <20170113182836-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <f4528c3e-4648-e9ef-0e01-b5cce3ede31b@redhat.com>

On Fri, Jan 13, 2017 at 10:45:09AM +0800, Jason Wang wrote:
> 
> 
> On 2017年01月12日 22:17, Michael S. Tsirkin wrote:
> > On Wed, Jan 11, 2017 at 12:32:12PM +0800, Jason Wang wrote:
> > > This patches implements Device IOTLB support for vhost kernel. This is
> > > done through:
> > > 
> > > 1) switch to use dma helpers when map/unmap vrings from vhost codes
> > > 2) introduce a set of VhostOps to:
> > >     - setting up device IOTLB request callback
> > >     - processing device IOTLB request
> > >     - processing device IOTLB invalidation
> > > 2) kernel support for Device IOTLB API:
> > > 
> > > - allow vhost-net to query the IOMMU IOTLB entry through eventfd
> > > - enable the ability for qemu to update a specified mapping of vhost
> > > - through ioctl.
> > > - enable the ability to invalidate a specified range of iova for the
> > >    device IOTLB of vhost through ioctl. In x86/intel_iommu case this is
> > >    triggered through iommu memory region notifier from device IOTLB
> > >    invalidation descriptor processing routine.
> > > 
> > > With all the above, kernel vhost_net can co-operate with userspace
> > > IOMMU. For vhost-user, the support could be easily done on top by
> > > implementing the VhostOps.
> > > 
> > > Cc: Michael S. Tsirkin<mst@redhat.com>
> > > Signed-off-by: Jason Wang<jasowang@redhat.com>
> > Applied, thanks!
> > 
> > > ---
> > > Changes from V4:
> > > - set iotlb callback only when IOMMU_PLATFORM is negotiated (fix
> > >    vhost-user qtest failure)
> > In fact this only checks virtio_host_has_feature - which is
> > the right thing to do, we can't trust the guest.
> > 
> > > - whitelist VIRTIO_F_IOMMU_PLATFORM instead of manually add it
> > > - keep cpu_physical_memory_map() in vhost_memory_map()
> > One further enhancement might be to detect that guest disabled
> > iommu (e.g. globally, or using iommu=pt) and disable
> > the iotlb to avoid overhead for guests which use DPDK
> > for assigned devices but not for vhost.
> > 
> > 
> 
> Yes, it's in my todo list.
> 
> Thanks

Something that I just noticed is that when user requests iommu_platform
but vhost can not provide it, this patches will just let vhost continue
without.  I think that's wrong, since iommu_platform is a security
feature, when it's not supported I think we should fail init.

-- 
MST

  reply	other threads:[~2017-01-13 16:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-11  4:32 [Qemu-devel] [PATCH V4 net-next] vhost_net: device IOTLB support Jason Wang
2017-01-11  4:36 ` Jason Wang
2017-01-12 14:17 ` Michael S. Tsirkin
2017-01-13  2:45   ` Jason Wang
2017-01-13 16:30     ` Michael S. Tsirkin [this message]
2017-01-16  3:33       ` Jason Wang

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=20170113182836-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=jasowang@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vkaplans@redhat.com \
    --cc=wexu@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.