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 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


  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