Discussion of the VIRTIO specification
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: tstark@linux.microsoft.com, virtio-comment@lists.oasis-open.org
Cc: grahamwo@microsoft.com, benhill@microsoft.com, mst@redhat.com,
	pankaj.gupta@ionos.com, Taylor Stark <tstark@microsoft.com>
Subject: Re: [virtio-comment] [PATCH 1/1] virtio-pmem: Support PCI BAR-relative addresses
Date: Thu, 22 Jul 2021 13:24:17 +0200	[thread overview]
Message-ID: <87k0li7fry.fsf@redhat.com> (raw)
In-Reply-To: <20210721205939.20746-2-tstark@linux.microsoft.com>

On Wed, Jul 21 2021, tstark@linux.microsoft.com wrote:

> From: Taylor Stark <tstark@microsoft.com>
>
> Update the virtio-pmem RFC spec to add support for describing the pmem region
> via PCI BARs. Shared memory windows are used to accomplish this, similar to
> virtio-fs and virtio-gpu. This is required to support virtio-pmem in Hyper-V,
> since Hyper-V only allows PCI devices to operate on memory ranges defined via
> BARs.

Given that we already have pmem support out there (even though the spec
has not been included yet, should this get a feature?

>
> Signed-off-by: Taylor Stark <tstark@microsoft.com>
> ---
>  virtio-pmem.tex | 22 +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/virtio-pmem.tex b/virtio-pmem.tex
> index 04e07bb..3f7d48e 100644
> --- a/virtio-pmem.tex
> +++ b/virtio-pmem.tex
> @@ -40,11 +40,21 @@ \subsection{Device Initialization}\label{sec:Device Types / PMEM Device / Device
>  Device hotplugs physical memory to guest address space. Persistent memory device
>  is emulated with file backed memory at host side.
>  
> +The device MUST indicate the guest physical address to the driver in one of two
> +ways:

This is not a normative section; better use "The device indicates...."?

>  \begin{enumerate}
> -\item Guest vpmem start is read from \field{start}.
> -\item Guest vpmem end is read from \field{size}.
> +\item As a guest absolute address.
> +\item As a shared memory region.
>  \end{enumerate}
>  
> +If the guest physical address is indicated as an absolute address, the device
> +MUST set \field{start} to the absolute address and \field{size} to the size of
> +the address range, in bytes.
> +
> +If the guest physical address is indicated as a shared memory region, the shared
> +memory region MUST be shared memory region ID 0. The device SHOULD set
> +\field{start} and \field{size} to zero.

And these two paragraphs should go into a normative section.

> +
>  \devicenormative{\subsubsection}{Device Initialization}{Device Types / PMEM Device / Device Initialization}
>  
>  File backed memory SHOULD be memory mapped to guest address space with SHARED
> @@ -52,9 +62,11 @@ \subsection{Device Initialization}\label{sec:Device Types / PMEM Device / Device
>  
>  \subsection{Driver Initialization}\label{sec:Device Types / PMEM Driver / Driver Initialization}
>  
> -Driver hotplugs the physical memory and registers associated
> -region with the pmem API. Also, configures a flush callback
> -function with the corresponding region.
> +The driver SHOULD query the physical address ranges where the pmem was mapped.
> +When performing the query, the driver MUST first query if shared memory region
> +ID 0 is supported by the device. If present, the driver MUST NOT use \field{start}
> +or \field{size}. If not present, the driver SHOULD fallback to reading the
> +physical address ranges from \field{start} and \field{size}.

Reading this, I think we really need to have a feature to distinguish
between the two modes; otherwise, old drivers will be confused.

Also, requirements belong in a normative section; it's better to just
describe textually what the driver needs to do here and split out the
normative statements.

>  
>  \drivernormative{\subsubsection}{Driver Initialization: Filesystem direct access}{Device Types / PMEM Driver / Driver Initialization / Direct access}


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


  reply	other threads:[~2021-07-22 11:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21 20:59 [virtio-comment] [PATCH 0/1] virtio-pmem: Support PCI BAR-relative addresses tstark
2021-07-21 20:59 ` [virtio-comment] [PATCH 1/1] " tstark
2021-07-22 11:24   ` Cornelia Huck [this message]
2021-07-22 23:26     ` Taylor Stark
2021-07-23  6:59       ` Cornelia Huck
2021-07-23  7:01       ` David Hildenbrand
2021-07-23 18:38         ` Taylor Stark
2021-07-23 19:18           ` David Hildenbrand
2021-07-27  4:21             ` Taylor Stark
2021-07-22 11:14 ` [virtio-comment] [PATCH 0/1] " Cornelia Huck
2021-07-22 11:30   ` Pankaj Gupta
2021-07-22 11:41     ` Cornelia Huck

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=87k0li7fry.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=benhill@microsoft.com \
    --cc=grahamwo@microsoft.com \
    --cc=mst@redhat.com \
    --cc=pankaj.gupta@ionos.com \
    --cc=tstark@linux.microsoft.com \
    --cc=tstark@microsoft.com \
    --cc=virtio-comment@lists.oasis-open.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