public inbox for virtio-dev@lists.linux.dev
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: virtio-dev@lists.oasis-open.org, cohuck@redhat.com,
	david.edmondson@oracle.com, sburla@marvell.com,
	jasowang@redhat.com, virtio-comment@lists.oasis-open.org,
	shahafs@nvidia.com
Subject: [virtio-dev] Re: [virtio-comment] Re: [PATCH v1 2/2] transport-pci: Add legacy register access conformance section
Date: Wed, 3 May 2023 15:18:52 -0400	[thread overview]
Message-ID: <20230503151509-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <f9ecf8f5-1be7-179c-4d96-1c44d4601710@nvidia.com>

On Wed, May 03, 2023 at 10:53:56AM -0400, Parav Pandit wrote:
> 
> 
> On 5/3/2023 1:48 AM, Michael S. Tsirkin wrote:
> > On Wed, May 03, 2023 at 06:26:59AM +0300, Parav Pandit wrote:
> > > Add device and driver conformanace section for legacy registers access
> > > commands interface.
> > > 
> > > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/167
> > > Signed-off-by: Parav Pandit <parav@nvidia.com>
> > > ---
> > >   conformance.tex           |  2 ++
> > >   transport-pci-vf-regs.tex | 31 +++++++++++++++++++++++++++++++
> > >   2 files changed, 33 insertions(+)
> > > 
> > > diff --git a/conformance.tex b/conformance.tex
> > > index 01ccd69..dbd8cd6 100644
> > > --- a/conformance.tex
> > > +++ b/conformance.tex
> > > @@ -109,6 +109,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > >   \item \ref{drivernormative:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / PCI configuration access capability}
> > >   \item \ref{drivernormative:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Device Initialization / MSI-X Vector Configuration}
> > >   \item \ref{drivernormative:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Notification of Device Configuration Changes}
> > > +\item \ref{drivernormative:Virtio Transport Options / Virtio Over PCI Bus / SR-IOV Legacy Registers Access}
> > >   \end{itemize}
> > >   \conformance{\subsection}{MMIO Driver Conformance}\label{sec:Conformance / Driver Conformance / MMIO Driver Conformance}
> > > @@ -194,6 +195,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > >   \item \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Device Initialization / MSI-X Vector Configuration}
> > >   \item \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Used Buffer Notifications}
> > >   \item \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Notification of Device Configuration Changes}
> > > +\item \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / SR-IOV Legacy Registers Access}
> > >   \end{itemize}
> > >   \conformance{\subsection}{MMIO Device Conformance}\label{sec:Conformance / Device Conformance / MMIO Device Conformance}
> > > diff --git a/transport-pci-vf-regs.tex b/transport-pci-vf-regs.tex
> > > index 16ced32..7d0574b 100644
> > > --- a/transport-pci-vf-regs.tex
> > > +++ b/transport-pci-vf-regs.tex
> > > @@ -82,3 +82,34 @@ \subsubsection{Legacy Queue Notify Offset Query}\label{sec:Virtio Transport Opti
> > >   	le64 offset; /* Byte offset within the BAR */
> > >   };
> > >   \end{lstlisting}
> > > +
> > > +\devicenormative{\paragraph}{SR-IOV VFs Legacy Registers Access}{Virtio Transport Options / Virtio Over PCI Bus / SR-IOV Legacy Registers Access}
> > > +
> > > +If the PCI PF device supports legacy registers access, it SHOULD set
> > > +corresponding bits for commands VIRTIO_ADMIN_CMD_LREG_WRITE,
> > > +VIRTIO_ADMIN_CMD_LREG_READ and VIRTIO_ADMIN_CMD_LQ_NOTIFY_QUERY in
> > > +command result of VIRTIO_ADMIN_CMD_LIST_QUERY in
> > > +\field{device_admin_cmd_opcodes}.
> > 
> > Don't repeat documentation of VIRTIO_ADMIN_CMD_LIST_QUERY please.
> yeah, I had dual thoughts, I am fine if this looks duplicate.
> Will remove.
> 
> > just say all these must be supported.
> > In fact what are you saying here? That all 3 are supported
> > or none at all? What about just
> > VIRTIO_ADMIN_CMD_LREG_READ/VIRTIO_ADMIN_CMD_LREG_WRITE?
> > Looks like a slower but working way to do notifications
> > is through a common config write, no?
> Notifications to be done using the notification region exposed and queried
> using the 3rd QUERY command.
> > 
> > > +
> > > +The device MUST support legacy configuration registers to its defined width.
> > 
> > what is this?
> > 
> Each register has its defined width as 8-bit, 16-bit, 32-bit etc.
> So device support the access to its defined width.
> May be to rewrite it differently?

Again you are duplicating the existing text, no?
And in this case, contradicting it?

	When using the legacy interface the driver MAY access
	the device-specific configuration region using any width accesses, and
	a transitional device MUST present driver with the same results as
	when accessed using the ``natural'' access method (i.e.
	32-bit accesses for 32-bit fields, etc).


> > > +
> > > +The device MAY fail legacy configuration registers access when either the
> > > +access is for an incorrct register width or if the register offset is incorrect.
> > 
> Spell checkers didnt capture the error of incorrct. Need to find better
> tool.
> 
> > with which error code?
> EINVAL
> but should we repeat the general section here?

this is a command specific case, isn't it?


> > 
> > > +
> > > +The device MUST allow access of one or multiple bytes of the registers when
> > > +such register is defined as byte array, for example \field{mac} of \field{struct
> > > +virtio_net_config} of the Network Device.
> > 
> > so which accesses need to be supported then?
> > 
> Not sure I follow the question.
> Can you please explain?

Consider mac, do you allow access to any length at all, from 1 to 6
bytes?


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2023-05-03 19:20 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-03  3:26 [virtio-dev] [PATCH v1 0/2] transport-pci: Introduce legacy registers access using AQ Parav Pandit
2023-05-03  3:26 ` [virtio-dev] [PATCH v1 1/2] transport-pci: Introduce legacy registers access commands Parav Pandit
2023-05-03  5:42   ` [virtio-dev] " Michael S. Tsirkin
2023-05-03 14:47     ` Parav Pandit
2023-05-03 16:48       ` Michael S. Tsirkin
2023-05-03 17:21         ` Parav Pandit
2023-05-04  6:30           ` Michael S. Tsirkin
2023-05-03  5:50   ` Michael S. Tsirkin
2023-05-03 14:49     ` Parav Pandit
2023-05-03 16:49       ` Michael S. Tsirkin
2023-05-03 17:23         ` Parav Pandit
2023-05-04  6:30           ` Michael S. Tsirkin
2023-05-03 19:21   ` Michael S. Tsirkin
2023-05-03 19:38     ` Parav Pandit
2023-05-03 20:08       ` Michael S. Tsirkin
2023-05-03 20:13         ` Parav Pandit
2023-05-05  3:26   ` Jason Wang
2023-05-05 12:48     ` [virtio-dev] " Parav Pandit
2023-05-06  2:24       ` [virtio-dev] " Jason Wang
2023-05-06  2:25         ` Jason Wang
2023-05-03  3:26 ` [virtio-dev] [PATCH v1 2/2] transport-pci: Add legacy register access conformance section Parav Pandit
2023-05-03  5:48   ` [virtio-dev] " Michael S. Tsirkin
2023-05-03 14:53     ` [virtio-dev] Re: [virtio-comment] " Parav Pandit
2023-05-03 19:18       ` Michael S. Tsirkin [this message]
2023-05-03 19:56         ` [virtio-dev] " Parav Pandit
2023-05-03 10:16 ` [virtio-dev] Re: [PATCH v1 0/2] transport-pci: Introduce legacy registers access using AQ Michael S. Tsirkin
2023-05-03 14:57   ` 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=20230503151509-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=david.edmondson@oracle.com \
    --cc=jasowang@redhat.com \
    --cc=parav@nvidia.com \
    --cc=sburla@marvell.com \
    --cc=shahafs@nvidia.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@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