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 1/3] shared-mem: introduce page alignment restrictions
Date: Wed, 2 Apr 2025 03:32:45 -0400 [thread overview]
Message-ID: <20250402030335-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20250331213711.63398-2-slp@redhat.com>
On Mon, Mar 31, 2025 at 05:37:09PM -0400, Sergio Lopez wrote:
> Add a subsection for page alignment restrictions and introduce the
> VIRTIO_F_SHM_PAGE_SIZE feature bit.
>
> Signed-off-by: Sergio Lopez <slp@redhat.com>
> ---
> content.tex | 10 ++++++++--
> shared-mem.tex | 7 +++++++
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/content.tex b/content.tex
> index c17ffa6..c8826a2 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -99,10 +99,10 @@ \section{Feature Bits}\label{sec:Basic Facilities of a Virtio Device / Feature B
> \begin{description}
> \item[0 to 23, and 50 to 127] Feature bits for the specific device type
>
> -\item[24 to 41] Feature bits reserved for extensions to the queue and
> +\item[24 to 42] Feature bits reserved for extensions to the queue and
> feature negotiation mechanisms, see \ref{sec:Reserved Feature Bits}
>
> -\item[42 to 49, and 128 and above] Feature bits reserved for future extensions.
> +\item[43 to 49, and 128 and above] Feature bits reserved for future extensions.
> \end{description}
>
> \begin{note}
> @@ -872,6 +872,12 @@ \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> \ref{devicenormative:Basic Facilities of a Virtio Device / Feature Bits} for
> handling features reserved for future use.
>
> + \item[VIRTIO_F_SHM_PAGE_SIZE(42)] This feature indicates that the device
> + transport provides information about the supported page size and expects the
> + driver to honor the alignment restrictions derived from it when requesting
> + mappings on the corresponding shared memory region.
> + See also \ref {sec:Basic Facilities of a Virtio Device / Shared Memory Regions / Page alignment restrictions}.
> +
> \end{description}
>
> \drivernormative{\section}{Reserved Feature Bits}{Reserved Feature Bits}
> diff --git a/shared-mem.tex b/shared-mem.tex
> index 6e6f6c4..dd90cb7 100644
> --- a/shared-mem.tex
> +++ b/shared-mem.tex
> @@ -34,6 +34,13 @@ \subsection{Addressing within regions}\label{sec:Basic Facilities of a Virtio De
> The \field{shmid} may be explicit or may be inferred from the
> context of the reference.
>
> +\subsection{Page alignment restrictions}\label{sec:Basic Facilities of a Virtio Device / Shared Memory Regions / Page alignment restrictions}
> +
> +If VIRTIO_F_SHM_PAGE_SIZE has been negotiated, when requesting
> +the device to map memory into a shared memory region, the driver
the shared memory region - it is this specific one.
> +MUST obtain the page size information from the transport
avoid MUST. Also not "from the transport". In a transport-specific way.
> and honor
> +the page alignment constrains derived from that page size.
Also explain here it is only supported for pci for now, to make
sure people do not go looking for it on other transports.
> +
> \devicenormative{\subsection}{Shared Memory Regions}{Basic Facilities of a Virtio
> Device / Shared Memory Regions}
> Shared memory regions MUST NOT expose shared memory regions which
I have a problem with this wording in that "map" and "request mapping"
is actually a device type specific thing. Someone reading this
paragraph will not know what this term means. Note also that the
term "map" has two meanings, e.g. device-types/fs/description.tex
says
In cases where data transfer is
undesirable, the device can map file contents into the DAX window shared memory
region.
but also
Drivers map this shared
memory region with writeback caching as if it were regular RAM.
I am guessing the "request mapping" refers to the 1st but not the 2nd
type of map, but neither mentions "request mapping".
My suggestions, but really just suggestions:
- update device specific text to mention alignment where appropriate,
using MUST there.
- Remove the MUST here, it is not good to have MUST outside non
conformance sections anyway.
- Avoid saying map since that is not
a generic term.
Just say generally
"information about the supported page size" and put all
the detail in device specific sections.
Also "device expects" is really a weird way to put things.
device does abc. driver does abc. that is all.
E.g.
When VIRTIO_F_SHM_PAGE_SIZE is negotiated, driver aligns
device requests
using shared memory regions on the supported page size of each
memory region, in a device-specific way. The supported
page size is retrieved in a transport-specific way. This feature
is only supported for the PCI transport (see ref to the relevant section).
And add device specific text where it applies.
> --
> 2.49.0
next prev parent reply other threads:[~2025-04-02 7:32 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 [this message]
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 ` [PATCH v3 0/3] shared-mem: introduce page alignment restrictions Michael S. Tsirkin
2025-04-02 9:18 ` 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=20250402030335-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