Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Jason Wang <jasowang@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Virtio-Dev <virtio-dev@lists.oasis-open.org>,
	eperezma <eperezma@redhat.com>, Cindy Lu <lulu@redhat.com>
Subject: Re: [virtio-dev] Re: [PATCH V2 2/2] virtio-pci: add PASID configuration extended capability
Date: Fri, 14 Jan 2022 10:38:03 +0000	[thread overview]
Message-ID: <YeFSi0ObDs/Dlp4e@myrica> (raw)
In-Reply-To: <52c6adef-d38e-fcab-105d-0c21e4a2aac2@redhat.com>

On Fri, Jan 14, 2022 at 11:15:35AM +0800, Jason Wang wrote:
> 
> 在 2022/1/13 下午11:17, Michael S. Tsirkin 写道:
> > On Thu, Jan 13, 2022 at 02:53:36PM +0000, Stefan Hajnoczi wrote:
> > > On Thu, Jan 13, 2022 at 05:45:11AM -0500, Michael S. Tsirkin wrote:
> > > > On Thu, Jan 13, 2022 at 10:32:11AM +0000, Stefan Hajnoczi wrote:
> > > > > > So my understanding is that instead of delaying the response to read
> > > > > > it's better to simply present the previous PASID value if there're any
> > > > > > pending transactions of previous PASID value. The driver can then
> > > > > > choose to poll or using timers etc.
> > > > Don't we limit these changes to before DRIVER_OK?
> > > > If we do then no previous transactions can exist.
> > > Not sure if that's possible for the vDPA virtqueue assignment use case
> > > where one large VIRTIO device provides virtqueues for many smaller vDPA
> > > devices?
> 
> 
> That could be the case but usually a smaller vDPA device requires a bunch of
> hardware resources more than just virtqueues.
> 
> Another example is assign a queue directly to userspace with PASID for SVA.
> 
> 
> > > 
> > > Stefan
> > Then I guess queue must be stopped?
> 
> 
> Yes, since we have virtqueue reset, I can limit the assigning before
> DRIVER_OK or queue(s) are reset. Does this work?

Yes, I was wondering how this would work for the SVA use-case, where
processes can request queues from the virtio driver at runtime:

* Process opens a fd to the queue
* virtio driver selects a disabled queue, gets a PASID for that
  task and assigns it to the queue's group 
* process mmaps its queue and works with it. When it is done, it closes
  the fd.
* virtio driver now makes sure that the virtqueue does not issue any
  more DMA with this PASID, it disables all the queues in the group by
  writing 1 to their queue_reset. After reset completes, it clears the
  group_pasid field.
* The driver releases the PASID (iommu_sva_unbind_device()).
  Both PASID and queue can now safely be assigned to other processes.

So making group_pasid field writeable only if all queues in the group are
disabled should work

Thanks,
Jean

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2022-01-14 10:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-12  5:57 [virtio-dev] [PATCH V2 0/2] virito-pci: PASID support Jason Wang
2022-01-12  5:57 ` [virtio-dev] [PATCH V2 1/2] virtio-pci: introduce virtio structure PCI Extended Capability Jason Wang
2022-01-12 10:10   ` [virtio-dev] " Stefan Hajnoczi
2022-01-13  0:55     ` Jason Wang
2022-01-13 10:19       ` Stefan Hajnoczi
2022-01-14  3:23         ` Jason Wang
2022-01-17 10:03           ` Stefan Hajnoczi
2022-01-12  5:57 ` [virtio-dev] [PATCH V2 2/2] virtio-pci: add PASID configuration extended capability Jason Wang
2022-01-12 10:41   ` [virtio-dev] " Stefan Hajnoczi
2022-01-13  1:24     ` Jason Wang
2022-01-13 10:32       ` Stefan Hajnoczi
2022-01-13 10:45         ` Michael S. Tsirkin
2022-01-13 14:53           ` Stefan Hajnoczi
2022-01-13 15:17             ` Michael S. Tsirkin
2022-01-14  3:15               ` Jason Wang
2022-01-14 10:38                 ` Jean-Philippe Brucker [this message]
2022-01-17  5:58                   ` Jason Wang
2022-01-14  9:43       ` Jean-Philippe Brucker
2022-01-17  5:57         ` Jason Wang
2022-01-19 18:01           ` Jean-Philippe Brucker
2022-01-19 23:53         ` Michael S. Tsirkin
2022-01-24 15:26           ` Jean-Philippe Brucker
2022-01-24 22:15             ` Michael S. Tsirkin
2022-01-12 10:44 ` [virtio-dev] Re: [PATCH V2 0/2] virito-pci: PASID support Stefan Hajnoczi
2022-01-13  1:28   ` Jason Wang
2022-01-13 10:36     ` Stefan Hajnoczi
2022-01-13 10:40       ` Michael S. Tsirkin
2022-01-14  2:53         ` Jason Wang
2022-01-13 15:18 ` Michael S. Tsirkin
2022-01-14  2:55   ` 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=YeFSi0ObDs/Dlp4e@myrica \
    --to=jean-philippe@linaro.org \
    --cc=eperezma@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=lulu@redhat.com \
    --cc=mst@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-dev@lists.oasis-open.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