qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Stevens <stevensd@chromium.org>
Cc: "Alyssa Ross" <hi@alyssa.is>,
	"Albert Esteve" <aesteve@redhat.com>,
	qemu-devel@nongnu.org, jasowang@redhat.com, david@redhat.com,
	slp@redhat.com, "Alex Bennée" <alex.bennee@linaro.org>,
	stefanha@redhat.com
Subject: Re: [RFC PATCH v2 0/5] vhost-user: Add SHMEM_MAP/UNMAP requests
Date: Fri, 12 Jul 2024 01:47:49 -0400	[thread overview]
Message-ID: <20240712014407-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAD=HUj7av_8Epkd0Fe0eWR7Z4bZMTuvTNgqzYoQcOzFQ82wvOg@mail.gmail.com>

On Fri, Jul 12, 2024 at 11:06:49AM +0900, David Stevens wrote:
> On Thu, Jul 11, 2024 at 7:56 PM Alyssa Ross <hi@alyssa.is> wrote:
> >
> > Adding David Stevens, who implemented SHMEM_MAP and SHMEM_UNMAP in
> > crosvm a couple of years ago.
> >
> > David, I'd be particularly interested for your thoughts on the MEM_READ
> > and MEM_WRITE commands, since as far as I know crosvm doesn't implement
> > anything like that.  The discussion leading to those being added starts
> > here:
> >
> > https://lore.kernel.org/qemu-devel/20240604185416.GB90471@fedora.redhat.com/
> >
> > It would be great if this could be standardised between QEMU and crosvm
> > (and therefore have a clearer path toward being implemented in other VMMs)!
> 
> Setting aside vhost-user for a moment, the DAX example given by Stefan
> won't work in crosvm today.
> 
> Is universal access to virtio shared memory regions actually mandated
> by the virtio spec? Copying from virtiofs DAX to virtiofs sharing
> seems reasonable enough, but what about virtio-pmem to virtio-blk?
> What about screenshotting a framebuffer in virtio-gpu shared memory to
> virtio-scsi? I guess with some plumbing in the VMM, it's solvable in a
> virtualized environment. But what about when you have real hardware
> that speaks virtio involved? That's outside my wheelhouse, but it
> doesn't seem like that would be easy to solve.

Yes, it can work for physical devices if allowed by host configuration.
E.g. VFIO supports that I think. Don't think VDPA does.

> For what it's worth, my interpretation of the target scenario:
> 
> > Other backends don't see these mappings. If the guest submits a vring
> > descriptor referencing a mapping to another backend, then that backend
> > won't be able to access this memory
> 
> is that it's omitting how the implementation is reconciled with
> section 2.10.1 of v1.3 of the virtio spec, which states that:
> 
> > References into shared memory regions are represented as offsets from
> > the beginning of the region instead of absolute memory addresses. Offsets
> > are used both for references between structures stored within shared
> > memory and for requests placed in virtqueues that refer to shared memory.
> 
> My interpretation of that statement is that putting raw guest physical
> addresses corresponding to virtio shared memory regions into a vring
> is a driver spec violation.
> 
> -David

This really applies within device I think. Should be clarified ...

-- 
MST



  reply	other threads:[~2024-07-12  5:49 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-28 14:57 [RFC PATCH v2 0/5] vhost-user: Add SHMEM_MAP/UNMAP requests Albert Esteve
2024-06-28 14:57 ` [RFC PATCH v2 1/5] vhost-user: Add VIRTIO Shared Memory map request Albert Esteve
2024-07-11  7:45   ` Stefan Hajnoczi
2024-09-03  9:54     ` Albert Esteve
2024-09-03 11:54       ` Albert Esteve
2024-09-05 16:45         ` Stefan Hajnoczi
2024-09-11 11:57           ` Albert Esteve
2024-09-11 14:54             ` Stefan Hajnoczi
2024-09-04  7:28     ` Albert Esteve
2024-06-28 14:57 ` [RFC PATCH v2 2/5] vhost_user: Add frontend command for shmem config Albert Esteve
2024-07-11  8:10   ` Stefan Hajnoczi
2024-09-04  9:05     ` Albert Esteve
2024-07-11  8:15   ` Stefan Hajnoczi
2024-06-28 14:57 ` [RFC PATCH v2 3/5] vhost-user-dev: Add cache BAR Albert Esteve
2024-07-11  8:25   ` Stefan Hajnoczi
2024-09-04 11:20     ` Albert Esteve
2024-06-28 14:57 ` [RFC PATCH v2 4/5] vhost_user: Add MEM_READ/WRITE backend requests Albert Esteve
2024-07-11  8:53   ` Stefan Hajnoczi
2024-06-28 14:57 ` [RFC PATCH v2 5/5] vhost_user: Implement mem_read/mem_write handlers Albert Esteve
2024-07-11  8:55   ` Stefan Hajnoczi
2024-09-04 13:01     ` Albert Esteve
2024-09-05 19:18       ` Stefan Hajnoczi
2024-09-10  7:14         ` Albert Esteve
2024-07-11  9:01 ` [RFC PATCH v2 0/5] vhost-user: Add SHMEM_MAP/UNMAP requests Stefan Hajnoczi
2024-07-11 10:56 ` Alyssa Ross
2024-07-12  2:06   ` David Stevens
2024-07-12  5:47     ` Michael S. Tsirkin [this message]
2024-07-15  2:30       ` Jason Wang
2024-07-16  1:21       ` David Stevens
2024-09-03  8:42         ` Albert Esteve
2024-09-05 16:39           ` Stefan Hajnoczi
2024-09-06  7:03             ` Albert Esteve
2024-09-06 13:15               ` Stefan Hajnoczi
2024-09-05 15:56         ` Stefan Hajnoczi
2024-09-06  4:18           ` David Stevens
2024-09-06 13:00             ` 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=20240712014407-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=aesteve@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=david@redhat.com \
    --cc=hi@alyssa.is \
    --cc=jasowang@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=slp@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=stevensd@chromium.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).