OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] [PATCH 1/1] virtio-pmem: Support PCI BAR-relative addresses


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}



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]