All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Shahaf Shuler <shahafs@mellanox.com>,
	Tiwei Bie <tiwei.bie@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jason Gunthorpe <jgg@mellanox.com>,
	"rob.miller@broadcom.com" <rob.miller@broadcom.com>,
	"haotian.wang@sifive.com" <haotian.wang@sifive.com>,
	"eperezma@redhat.com" <eperezma@redhat.com>,
	"lulu@redhat.com" <lulu@redhat.com>,
	Parav Pandit <parav@mellanox.com>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"hch@infradead.org" <hch@infradead.org>,
	Jiri Pirko <jiri@mellanox.com>,
	"hanand@xilinx.com" <hanand@xilinx.com>,
	mhabets@solarflar
Subject: Re: [PATCH] vhost: introduce vDPA based backend
Date: Wed, 5 Feb 2020 04:23:59 -0500	[thread overview]
Message-ID: <20200205042259-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <112858a4-1a01-f4d7-e41a-1afaaa1cad45@redhat.com>

On Wed, Feb 05, 2020 at 03:50:14PM +0800, Jason Wang wrote:
> 
> On 2020/2/5 下午3:15, Shahaf Shuler wrote:
> > Wednesday, February 5, 2020 4:03 AM, Tiwei Bie:
> > > Subject: Re: [PATCH] vhost: introduce vDPA based backend
> > > 
> > > On Tue, Feb 04, 2020 at 11:30:11AM +0800, Jason Wang wrote:
> > > > On 2020/1/31 上午11:36, Tiwei Bie wrote:
> > > > > This patch introduces a vDPA based vhost backend. This backend is
> > > > > built on top of the same interface defined in virtio-vDPA and
> > > > > provides a generic vhost interface for userspace to accelerate the
> > > > > virtio devices in guest.
> > > > > 
> > > > > This backend is implemented as a vDPA device driver on top of the
> > > > > same ops used in virtio-vDPA. It will create char device entry named
> > > > > vhost-vdpa/$vdpa_device_index for userspace to use. Userspace can
> > > > > use vhost ioctls on top of this char device to setup the backend.
> > > > > 
> > > > > Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> > [...]
> > 
> > > > > +static long vhost_vdpa_do_dma_mapping(struct vhost_vdpa *v) {
> > > > > +	/* TODO: fix this */
> > > > 
> > > > Before trying to do this it looks to me we need the following during
> > > > the probe
> > > > 
> > > > 1) if set_map() is not supported by the vDPA device probe the IOMMU
> > > > that is supported by the vDPA device
> > > > 2) allocate IOMMU domain
> > > > 
> > > > And then:
> > > > 
> > > > 3) pin pages through GUP and do proper accounting
> > > > 4) store GPA->HPA mapping in the umem
> > > > 5) generate diffs of memory table and using IOMMU API to setup the dma
> > > > mapping in this method
> > > > 
> > > > For 1), I'm not sure parent is sufficient for to doing this or need to
> > > > introduce new API like iommu_device in mdev.
> > > Agree. We may also need to introduce something like the iommu_device.
> > > 
> > Would it be better for the map/umnap logic to happen inside each device ?
> > Devices that needs the IOMMU will call iommu APIs from inside the driver callback.
> 
> 
> Technically, this can work. But if it can be done by vhost-vpda it will make
> the vDPA driver more compact and easier to be implemented.
> 
> 
> > Devices that has other ways to do the DMA mapping will call the proprietary APIs.
> 
> 
> To confirm, do you prefer:
> 
> 1) map/unmap
> 
> or
> 
> 2) pass all maps at one time?
> 
> Thanks
> 
> 

I mean we really already have both right? ATM 1 is used with an iommu
and 2 without. I guess we can also have drivers ask for either or both
...

-- 
MST

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Shahaf Shuler <shahafs@mellanox.com>,
	Tiwei Bie <tiwei.bie@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org" 
	<virtualization@lists.linux-foundation.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jason Gunthorpe <jgg@mellanox.com>,
	"rob.miller@broadcom.com" <rob.miller@broadcom.com>,
	"haotian.wang@sifive.com" <haotian.wang@sifive.com>,
	"eperezma@redhat.com" <eperezma@redhat.com>,
	"lulu@redhat.com" <lulu@redhat.com>,
	Parav Pandit <parav@mellanox.com>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"hch@infradead.org" <hch@infradead.org>,
	Jiri Pirko <jiri@mellanox.com>,
	"hanand@xilinx.com" <hanand@xilinx.com>,
	"mhabets@solarflare.com" <mhabets@solarflare.com>,
	"maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
	"lingshan.zhu@intel.com" <lingshan.zhu@intel.com>,
	"dan.daly@intel.com" <dan.daly@intel.com>,
	"cunming.liang@intel.com" <cunming.liang@intel.com>,
	"zhihong.wang@intel.com" <zhihong.wang@intel.com>
Subject: Re: [PATCH] vhost: introduce vDPA based backend
Date: Wed, 5 Feb 2020 04:23:59 -0500	[thread overview]
Message-ID: <20200205042259-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <112858a4-1a01-f4d7-e41a-1afaaa1cad45@redhat.com>

On Wed, Feb 05, 2020 at 03:50:14PM +0800, Jason Wang wrote:
> 
> On 2020/2/5 下午3:15, Shahaf Shuler wrote:
> > Wednesday, February 5, 2020 4:03 AM, Tiwei Bie:
> > > Subject: Re: [PATCH] vhost: introduce vDPA based backend
> > > 
> > > On Tue, Feb 04, 2020 at 11:30:11AM +0800, Jason Wang wrote:
> > > > On 2020/1/31 上午11:36, Tiwei Bie wrote:
> > > > > This patch introduces a vDPA based vhost backend. This backend is
> > > > > built on top of the same interface defined in virtio-vDPA and
> > > > > provides a generic vhost interface for userspace to accelerate the
> > > > > virtio devices in guest.
> > > > > 
> > > > > This backend is implemented as a vDPA device driver on top of the
> > > > > same ops used in virtio-vDPA. It will create char device entry named
> > > > > vhost-vdpa/$vdpa_device_index for userspace to use. Userspace can
> > > > > use vhost ioctls on top of this char device to setup the backend.
> > > > > 
> > > > > Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> > [...]
> > 
> > > > > +static long vhost_vdpa_do_dma_mapping(struct vhost_vdpa *v) {
> > > > > +	/* TODO: fix this */
> > > > 
> > > > Before trying to do this it looks to me we need the following during
> > > > the probe
> > > > 
> > > > 1) if set_map() is not supported by the vDPA device probe the IOMMU
> > > > that is supported by the vDPA device
> > > > 2) allocate IOMMU domain
> > > > 
> > > > And then:
> > > > 
> > > > 3) pin pages through GUP and do proper accounting
> > > > 4) store GPA->HPA mapping in the umem
> > > > 5) generate diffs of memory table and using IOMMU API to setup the dma
> > > > mapping in this method
> > > > 
> > > > For 1), I'm not sure parent is sufficient for to doing this or need to
> > > > introduce new API like iommu_device in mdev.
> > > Agree. We may also need to introduce something like the iommu_device.
> > > 
> > Would it be better for the map/umnap logic to happen inside each device ?
> > Devices that needs the IOMMU will call iommu APIs from inside the driver callback.
> 
> 
> Technically, this can work. But if it can be done by vhost-vpda it will make
> the vDPA driver more compact and easier to be implemented.
> 
> 
> > Devices that has other ways to do the DMA mapping will call the proprietary APIs.
> 
> 
> To confirm, do you prefer:
> 
> 1) map/unmap
> 
> or
> 
> 2) pass all maps at one time?
> 
> Thanks
> 
> 

I mean we really already have both right? ATM 1 is used with an iommu
and 2 without. I guess we can also have drivers ask for either or both
...

-- 
MST


  reply	other threads:[~2020-02-05  9:23 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31  3:36 [PATCH] vhost: introduce vDPA based backend Tiwei Bie
2020-01-31  3:56 ` Randy Dunlap
2020-01-31  5:12   ` Randy Dunlap
2020-01-31  5:54     ` Tiwei Bie
2020-01-31  5:52   ` Tiwei Bie
2020-02-04  3:30 ` Jason Wang
2020-02-04  6:01   ` Michael S. Tsirkin
2020-02-04  6:01     ` Michael S. Tsirkin
2020-02-04  6:46     ` Jason Wang
2020-02-05  2:05       ` Tiwei Bie
2020-02-05  3:12         ` Jason Wang
2020-02-05  5:31           ` Michael S. Tsirkin
2020-02-05  5:50             ` Jason Wang
2020-02-05  5:50               ` Jason Wang
2020-02-05  6:30               ` Michael S. Tsirkin
2020-02-05  6:49                 ` Jason Wang
2020-02-05  6:49                   ` Jason Wang
2020-02-05  7:16                   ` Michael S. Tsirkin
2020-02-05  7:42                     ` Jason Wang
2020-02-05  9:22                       ` Michael S. Tsirkin
2020-02-05  2:02   ` Tiwei Bie
2020-02-05  3:11     ` Jason Wang
2020-02-05  7:15     ` Shahaf Shuler
2020-02-05  7:15       ` Shahaf Shuler
2020-02-05  7:50       ` Jason Wang
2020-02-05  7:50         ` Jason Wang
2020-02-05  9:23         ` Michael S. Tsirkin [this message]
2020-02-05  9:23           ` Michael S. Tsirkin
2020-02-06  3:07           ` Jason Wang
2020-02-06  3:07             ` Jason Wang
2020-02-05  9:30         ` Shahaf Shuler
2020-02-05  9:30           ` Shahaf Shuler
2020-02-05 10:33           ` Michael S. Tsirkin
2020-02-05 10:33             ` Michael S. Tsirkin
2020-02-06  3:09             ` Jason Wang
2020-02-06  3:09               ` Jason Wang
2020-02-06  3:04           ` Jason Wang
2020-02-06  3:04             ` Jason Wang
2020-02-05 12:56         ` Jason Gunthorpe
2020-02-05 12:56           ` Jason Gunthorpe
2020-02-05 13:14           ` Michael S. Tsirkin
2020-02-05 13:14             ` Michael S. Tsirkin
2020-02-06  3:11             ` Jason Wang
2020-02-06  3:11               ` Jason Wang
2020-02-06  3:21               ` Zhu Lingshan
2020-02-06  3:21                 ` Zhu Lingshan
2020-02-18 13:53 ` Jason Gunthorpe
2020-02-19  2:52   ` Tiwei Bie
2020-02-19 13:11     ` Jason Gunthorpe
2020-02-20  2:42       ` Tiwei Bie

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=20200205042259-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=eperezma@redhat.com \
    --cc=hanand@xilinx.com \
    --cc=haotian.wang@sifive.com \
    --cc=hch@infradead.org \
    --cc=jasowang@redhat.com \
    --cc=jgg@mellanox.com \
    --cc=jiri@mellanox.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mhabets@solarflar \
    --cc=netdev@vger.kernel.org \
    --cc=parav@mellanox.com \
    --cc=rdunlap@infradead.org \
    --cc=rob.miller@broadcom.com \
    --cc=shahafs@mellanox.com \
    --cc=tiwei.bie@intel.com \
    --cc=virtualization@lists.linux-foundation.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 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.