qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Tiwei Bie <tiwei.bie@intel.com>,
	qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org,
	mst@redhat.com, alex.williamson@redhat.com, jasowang@redhat.com,
	stefanha@redhat.com
Cc: cunming.liang@intel.com, dan.daly@intel.com,
	jianfeng.tan@intel.com, zhihong.wang@intel.com,
	xiao.w.wang@intel.com
Subject: Re: [Qemu-devel] [virtio-dev] [PATCH v1 6/6] vhost-user: add VFIO based accelerators support
Date: Mon, 5 Feb 2018 18:47:51 +0100	[thread overview]
Message-ID: <2e83b7fa-8cec-4c13-003f-f753a13fbfe2@redhat.com> (raw)
In-Reply-To: <20180125040328.22867-7-tiwei.bie@intel.com>

On 25/01/2018 05:03, Tiwei Bie wrote:
> The key difference with PCI passthru is that, in this case only
> the data path of the device (e.g. DMA ring, notify region and
> queue interrupt) is pass-throughed to the VM, the device control
> path (e.g. PCI configuration space and MMIO regions) is still
> defined and emulated by QEMU.
> 
> The benefits of keeping virtio device emulation in QEMU compared
> with virtio device PCI passthru include (but not limit to):
> 
> - consistent device interface for guest OS in the VM;
> - max flexibility on the hardware (i.e. the accelerators) design;
> - leveraging the existing virtio live-migration framework;
> 
> The virtual IOMMU isn't supported by the accelerators for now.
> Because vhost-user currently lacks of an efficient way to share
> the IOMMU table in VM to vhost backend. That's why the software
> implementation of virtual IOMMU support in vhost-user backend
> can't support dynamic mapping well. Once this problem is solved
> in vhost-user, virtual IOMMU can be supported by accelerators
> too, and the IOMMU feature bit checking in this patch can be
> removed.

I don't understand why this would use vhost-user.  vhost-user is meant
for connecting to e.g. a user-space switch that is shared between
multiple virtual machines.

In this case, there would be one VFIO device per VM (because different
VM must be in different VFIO groups).  So I don't understand the benefit
of configuring the control path of the VFIO device outside QEMU.

Paolo

  parent reply	other threads:[~2018-02-05 17:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-25  4:03 [Qemu-devel] [PATCH v1 0/6] Extend vhost-user to support VFIO based accelerators Tiwei Bie
2018-01-25  4:03 ` [Qemu-devel] [PATCH v1 1/6] vhost-user: support receiving file descriptors in slave_read Tiwei Bie
2018-01-25  4:03 ` [Qemu-devel] [PATCH v1 2/6] vhost-user: introduce shared vhost-user state Tiwei Bie
2018-01-25  4:03 ` [Qemu-devel] [PATCH v1 3/6] virtio: support adding sub-regions for notify region Tiwei Bie
2018-01-25  4:03 ` [Qemu-devel] [PATCH v1 4/6] vfio: support getting VFIOGroup from groupfd Tiwei Bie
2018-01-25  4:03 ` [Qemu-devel] [PATCH v1 5/6] vfio: remove DPRINTF() definition from vfio-common.h Tiwei Bie
2018-01-25  4:03 ` [Qemu-devel] [PATCH v1 6/6] vhost-user: add VFIO based accelerators support Tiwei Bie
2018-01-25 23:59   ` Michael S. Tsirkin
2018-01-26  3:41     ` [Qemu-devel] [virtio-dev] " Jason Wang
2018-01-26  5:57       ` Tiwei Bie
2018-02-04 21:49         ` Alexander Duyck
2018-02-07 16:43           ` Michael S. Tsirkin
2018-02-07 18:02             ` Alexander Duyck
2018-02-07 21:59               ` Michael S. Tsirkin
2018-02-05 17:47   ` Paolo Bonzini [this message]
2018-02-06  4:40     ` [Qemu-devel] [virtio-dev] " Tiwei Bie
2018-02-07 15:23       ` Paolo Bonzini
2018-01-25 14:22 ` [Qemu-devel] [PATCH v1 0/6] Extend vhost-user to support VFIO based accelerators Stefan Hajnoczi
2018-01-25 16:10   ` Liang, Cunming
2018-01-26  7:17     ` Stefan Hajnoczi

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=2e83b7fa-8cec-4c13-003f-f753a13fbfe2@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=cunming.liang@intel.com \
    --cc=dan.daly@intel.com \
    --cc=jasowang@redhat.com \
    --cc=jianfeng.tan@intel.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=tiwei.bie@intel.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=xiao.w.wang@intel.com \
    --cc=zhihong.wang@intel.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 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).