public inbox for virtio-comment@lists.linux.dev
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Sergio Lopez <slp@redhat.com>
Cc: virtio-comment@lists.linux.dev, dmitry.osipenko@collabora.com,
	parav@nvidia.com
Subject: Re: [PATCH v3 0/3] shared-mem: introduce page alignment restrictions
Date: Wed, 2 Apr 2025 03:37:31 -0400	[thread overview]
Message-ID: <20250402033354-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20250331213711.63398-1-slp@redhat.com>

On Mon, Mar 31, 2025 at 05:37:08PM -0400, Sergio Lopez wrote:
> There's an incresing number of machines supporting multiple page sizes
> and, on these machines, the host and a guest can be running with
> different pages sizes.
> 
> In addition to this, there might be devices that have a required and/or
> preferred page size for mapping memory.
> 
> In this series we extend the "Shared Memory Regions" with a subsection
> explaining the posible existence of page alignment restrictions when
> the VIRTIO_F_SHM_PAGE_SIZE feature has been negotiated.
> 
> For the device to provide the page size information to the driver, we
> need to extend the PCI and MMIO transports. For the former, we borrow
> 8 bits from the 16 bit padding in virtio_pci_cap to hold a page_shift
> field which can be used to derive the page size by using the following
> formula: (page_size = 1 << (page_shift + 12)).
> 
> For MMIO, we add a the SHMPageShift register at offset 0x0c4, also
> holding the page_shift value. Since MMIO registers are 32 bit wide, we
> could have asked the device to directly provide page_size instead of
> page_shift, but seems reasonable to be consistent across transports.
> 
> An implementation of the changes proposed in this series has been
> published as an RFC to the LKML, to be used as a reference:
> 
> https://lore.kernel.org/all/20250214-virtio-shm-page-size-v2-0-aa1619e6908b@redhat.com/


Can you explain the use a bit more please?

- looks like this is exposed to userspace?
  but userspace can not be trusted not to violate the spec.
  how can that be sufficient to satisfy MUST requirements?

  what are these mappings and what are the alignment restrictions,
  in fact?


Looking at that patch, I begin to suspect that while the spec patch talks about
device mapping requests, it is actually the other way around:
the restriction is on guest virtual to guest physical mappings?


Does the feature affect other device types besides gpu, and how?







> v3:
>  - Reintroduce the VIRTIO_F_SHM_PAGE_SIZE feature bit, but limit its
>    scope to page alignment restrictions, still exposing page shift
>    data in the transports unconditionally (thanks Michael S. Tsirkin)
>  - Adjust the feature bits to reflect we're using another one (thanks
>    Parav Pandit).
> 
> v2:
>  - Remove the VIRTIO_F_SHM_PAGE_SIZE feature bit, exposing page_shift
>    in the transports unconditionally (thanks Parav Pandit).
>  - Didn't pick up R-b due to the significant change between revisions.
> 
> Sergio Lopez (3):
>   shared-mem: introduce page alignment restrictions
>   transport-pci: introduce page_shift field for SHM
>   transport-mmio: introduce SHMPageShift register
> 
>  content.tex        | 10 ++++++++--
>  shared-mem.tex     |  7 +++++++
>  transport-mmio.tex |  8 ++++++++
>  transport-pci.tex  | 10 +++++++++-
>  4 files changed, 32 insertions(+), 3 deletions(-)
> 
> -- 
> 2.49.0


  parent reply	other threads:[~2025-04-02  7:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-31 21:37 [PATCH v3 0/3] shared-mem: introduce page alignment restrictions Sergio Lopez
2025-03-31 21:37 ` [PATCH v3 1/3] " Sergio Lopez
2025-04-01 16:42   ` Daniel Verkamp
2025-04-02  7:32   ` Michael S. Tsirkin
2025-03-31 21:37 ` [PATCH v3 2/3] transport-pci: introduce page_shift field for SHM Sergio Lopez
2025-03-31 21:37 ` [PATCH v3 3/3] transport-mmio: introduce SHMPageShift register Sergio Lopez
2025-04-02  7:37 ` Michael S. Tsirkin [this message]
2025-04-02  9:18   ` [PATCH v3 0/3] shared-mem: introduce page alignment restrictions Sergio Lopez Pascual
2025-04-02  9:55     ` Parav Pandit
2025-04-02 12:22       ` Sergio Lopez Pascual
2025-04-02 12:36         ` Parav Pandit
2025-04-02 14:49       ` Michael S. Tsirkin
2025-04-02 16:28         ` Sergio Lopez Pascual
2025-04-02  8:54 ` Parav Pandit

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=20250402033354-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=parav@nvidia.com \
    --cc=slp@redhat.com \
    --cc=virtio-comment@lists.linux.dev \
    /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