From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: virtio-dev@lists.oasis-open.org,
virtio-comment@lists.oasis-open.org, stefanha@redha.com,
cohuck@redhat.com
Subject: [virtio-comment] Re: [virtio-dev] [PATCH v4 2/3] shared memory: Define PCI capability
Date: Thu, 20 Jun 2019 01:43:55 -0400 [thread overview]
Message-ID: <20190620014102-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20190619171045.GE2844@work-vm>
On Wed, Jun 19, 2019 at 06:10:45PM +0100, Dr. David Alan Gilbert wrote:
> * Michael S. Tsirkin (mst@redhat.com) wrote:
> > On Wed, Mar 20, 2019 at 12:07:39PM +0000, Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > >
> > > Define the PCI capability used for enumerating shared memory regions.
> > >
> > > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> > > Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> > > ---
> > > content.tex | 37 +++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 37 insertions(+)
> > >
> > > diff --git a/content.tex b/content.tex
> > > index 8cd1a38..ddbf949 100644
> > > --- a/content.tex
> > > +++ b/content.tex
> > > @@ -688,6 +688,8 @@ The fields are interpreted as follows:
> > > #define VIRTIO_PCI_CAP_DEVICE_CFG 4
> > > /* PCI configuration access */
> > > #define VIRTIO_PCI_CAP_PCI_CFG 5
> > > +/* Shared memory region */
> > > +#define VIRTIO_PCI_CAP_SHARED_MEMORY_CFG 8
> > > \end{lstlisting}
> > >
> > > Any other value is reserved for future use.
> > > @@ -1052,6 +1054,41 @@ any device type which has a device-specific configuration.
> > >
> > > The \field{offset} for the device-specific configuration MUST be 4-byte aligned.
> > >
> > > +\subsubsection{Shared memory capability}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Shared memory capability}
> > > +
> > > +Shared memory regions \ref{sec:Basic Facilities of a Virtio
> > > +Device / Shared Memory Regions} are enumerated on the PCI transport
> > > +as a sequence of VIRTIO_PCI_CAP_SHARED_MEMORY_CFG capabilities, one per region.
> > > +
> > > +The capability is immediately followed by an additional field like so:
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_pci_shm_cap {
> > > + struct virtio_pci_cap cap;
> > > + u32 offset_hi;
> > > + u32 length_hi;
> > > + u8 id;
> >
> > Pls pad, pci capabilities must be a multiple of 4 bytes.
> > BTW virtio_pci_cap has 3 bytes of padding.
> > We can stick the id there maybe?
>
> Do you mean changing the def of virtio_pci_cap to: ?
> struct virtio_pci_cap {
> __u8 cap_vndr; /* Generic PCI field: PCI_CAP_ID_VNDR */
> __u8 cap_next; /* Generic PCI field: next ptr. */
> __u8 cap_len; /* Generic PCI field: capability length */
> __u8 cfg_type; /* Identifies the structure. */
> __u8 bar; /* Where to find it. */
> __u8 id; /* Unique ID for this region */
> __u8 padding[2]; /* Pad to full dword. */
> __le32 offset; /* Offset within bar. */
> __le32 length; /* Length of the structure, in bytes. */
> };
Something like this, yes.
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +Given that the \field{cap.length} and \field{cap.offset} fields
> > > +are only 32 bit, the additional \field{offset_hi} and \field {length_hi}
> > > +fields provide the most significant 32 bits of a total 64 bit offset and
> > > +length within the bar specified by \field{cap.bar}. \field{id}
> > > +uniquely identifies the given shared memory region using a device
> > > +specific identifier.
> >
> > I didn't realize we will ever need so much space. I think I prefer
> > moving offset_hi/length_hi to a general virtio_pci_cap64 that others can
> > reuse.
>
> Would we then just rename virtio_pci_shm_cap to virtio_pci_cap64 after
> moving the id to virito_pci_cap?
Right except we then need to document that only shm uses cap64, others
use cap. And I guess for forward compatibility set a bit somewhere - within bar maybe?
Overall I'm no longer sure it's a good idea. you decide.
> >
> >
> > > +
> > > +While most capabilities can not be repeated,
> >
> > I'd drop this part.
>
> Done.
>
> > > multiple
> > > +VIRTIO_PCI_CAP_SHARED_MEMORY_CFG capabilities are allowed as long
> > > +as the \field{id} is unique.
> > > +
> > > +\devicenormative{\paragraph}{Device-specific configuration}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Shared memory capability}
> > > +
> > > +The region defined by the combination of the offsets and length
> > > +fields
> >
> > let's do \field{cap.length} \field{cap.offset} etc.
>
> I've done that as:
> The region defined by the combination of the \field {cap.offset},
> \field {cap.offset_hi}, and \field {cap.length}, \field
> {cap.length_hi} fields MUST be contained within the declared bar.
>
> is that right, but the base and hi are in separate structures.
ok
> > >MUST be contained within the declared bar.
> > > +
> > > +The \field{id} MUST be unique for any one device instance.
> > > +
> > > \subsubsection{PCI configuration access capability}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / PCI configuration access capability}
> > >
> > > The VIRTIO_PCI_CAP_PCI_CFG capability
> > > --
> > > 2.20.1
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
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/
next prev parent reply other threads:[~2019-06-20 5:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-20 12:07 [virtio-comment] [PATCH v4 0/3] Large shared memory regions Dr. David Alan Gilbert (git)
2019-03-20 12:07 ` [virtio-comment] [PATCH v4 1/3] shared memory: Define " Dr. David Alan Gilbert (git)
2019-06-17 18:30 ` Michael S. Tsirkin
2019-06-19 16:06 ` Dr. David Alan Gilbert
2019-06-19 16:24 ` Michael S. Tsirkin
2019-06-21 20:42 ` Michael S. Tsirkin
2019-06-27 16:35 ` [virtio-comment] Re: [virtio-dev] " Dr. David Alan Gilbert
2019-03-20 12:07 ` [virtio-comment] [PATCH v4 2/3] shared memory: Define PCI capability Dr. David Alan Gilbert (git)
2019-06-17 18:36 ` [virtio-comment] Re: [virtio-dev] " Michael S. Tsirkin
2019-06-17 18:41 ` Michael S. Tsirkin
2019-06-19 17:13 ` Dr. David Alan Gilbert
2019-06-20 5:45 ` Michael S. Tsirkin
2019-06-21 20:38 ` [virtio-comment] Re: [virtio-dev] " Michael S. Tsirkin
2019-06-19 17:10 ` Dr. David Alan Gilbert
2019-06-20 5:43 ` Michael S. Tsirkin [this message]
2019-06-21 20:39 ` Michael S. Tsirkin
2019-03-20 12:07 ` [virtio-comment] [PATCH v4 3/3] shared memory: Define mmio registers Dr. David Alan Gilbert (git)
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=20190620014102-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cohuck@redhat.com \
--cc=dgilbert@redhat.com \
--cc=stefanha@redha.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.