All of lore.kernel.org
 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 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.