From: Venu Busireddy <venu.busireddy@oracle.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>,
virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [virtio-dev] Re: [PATCH virtio 1/1] Add "Group Identifier" support to virtio PCI capabilities.
Date: Tue, 19 Jun 2018 12:54:06 -0500 [thread overview]
Message-ID: <20180619175406.GA14192@lt> (raw)
In-Reply-To: <20180619202529-mutt-send-email-mst@kernel.org>
On 2018-06-19 20:30:06 +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 19, 2018 at 11:32:28AM -0500, Venu Busireddy wrote:
> > Add VIRTIO_PCI_CAP_GROUP_ID_CFG (Group Identifier) capability to the
> > virtio PCI capabilities to allow for the grouping of devices.
> >
> > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
> > ---
> > content.tex | 43 +++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 43 insertions(+)
> >
> > diff --git a/content.tex b/content.tex
> > index 7a92cb1..7ea6267 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -599,6 +599,8 @@ The fields are interpreted as follows:
> > #define VIRTIO_PCI_CAP_DEVICE_CFG 4
> > /* PCI configuration access */
> > #define VIRTIO_PCI_CAP_PCI_CFG 5
> > +/* Group Identifier */
> > +#define VIRTIO_PCI_CAP_GROUP_ID_CFG 6
> > \end{lstlisting}
> >
> > Any other value is reserved for future use.
> > @@ -997,6 +999,47 @@ address \field{cap.length} bytes within a BAR range
> > specified by some other Virtio Structure PCI Capability
> > of type other than \field{VIRTIO_PCI_CAP_PCI_CFG}.
> >
> > +\subsubsection{Group Identifier capability}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Group Identifier capability}
> > +
> > +The VIRTIO_PCI_CAP_GROUP_ID_CFG capability provides means for grouping devices together.
> > +
> > +The capability is immediately followed by an identifier of arbitrary size as below:
> > +
> > +\begin{lstlisting}
> > +struct virtio_pci_group_id_cap {
> > + struct virtio_pci_cap cap;
> > + u8 group_id[]; /* Group Identifier */
> > +};
> > +\end{lstlisting}
> > +
> > +The fields \field{cap.bar}, \field{cap.length}, \field{cap.offset}
> > +and \field{group_id} are read-only for the driver.
> > +
> > +The specification does not impose any restrictions on the size or
> > +structure of group_id[].
>
> I think it must be a multiple of 4 in size, as is
> standard for all capabilities.
Sure. Would rephrasing it as below suffice?
The specification does not impose any restrictions on the size or
structure of group_id[], except that the size must be a multiple of 4.
>
>
> > Vendors are free to declare this array as
> > +large as needed, as long as the combined size of all capabilities can
> > +be accommodated within the PCI configuration space.
> > +
> > +If there is enough room in the PCI configuration space to accommodate
> > +the group identifier, the fields \field{cap.bar}, \field{cap.offset}
> > +and \field{cap.length} should be set to 0.
> > +
> > +If there isn't enough room, some or all of the group identifier can be
> > +presented in the BAR region, in which case the fields \field{cap.bar},
> > +\field{cap.offset} and \field{cap.length} should be set appropriately.
>
> And then how do you glue the two pieces?
How the user glues them up is up to the user. The specification should
not impose rules on that, right?
>
> > +
> > +In either case, the field \field{cap.cap_len} indicates the length of
> > +the group identifier information present in the configuration space
> > +itself.
>
> It seems like an overkill to me. Isn't it enough to have it in config
> space? This would make comparisons easier.
I was trying to make the proposal permissive for expansion, in case
the user needs the size to be larger than what can be accommodated in
the config space. Would you like me to restrict that the capability be
entirely present in the config space? I am fine with it. Please confirm,
and I will change it so.
>
> > +
> > +\devicenormative{\paragraph}{Group Identifier capability}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Group Identifier capability}
> > +
> > +The device MAY present the VIRTIO_PCI_CAP_GROUP_ID_CFG capability.
> > +
> > +\drivernormative{\paragraph}{Group Identifier capability}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Group Identifier capability}
> > +
> > +The driver MUST NOT write to group_id[] area or the BAR region.
> > +
> > \subsubsection{Legacy Interfaces: A Note on PCI Device Layout}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Legacy Interfaces: A Note on PCI Device Layout}
> >
> > Transitional devices MUST present part of configuration
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
next prev parent reply other threads:[~2018-06-19 17:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-19 16:32 [Qemu-devel] [PATCH 0/3] Use of unique identifier for pairing virtio and passthrough devices Venu Busireddy
2018-06-19 16:32 ` [Qemu-devel] [PATCH 1/3] Add a true or false option to the DEFINE_PROP_UUID macro Venu Busireddy
2018-06-19 16:32 ` [Qemu-devel] [PATCH 2/3] Add "Group Identifier" support to PCIe bridges Venu Busireddy
2018-06-19 17:24 ` Michael S. Tsirkin
2018-06-19 18:14 ` [Qemu-devel] [virtio-dev] " Venu Busireddy
2018-06-19 18:21 ` Michael S. Tsirkin
2018-06-19 18:36 ` Venu Busireddy
2018-06-19 18:53 ` Michael S. Tsirkin
2018-06-19 19:02 ` Venu Busireddy
2018-06-19 19:10 ` Michael S. Tsirkin
2018-06-19 16:32 ` [Qemu-devel] [PATCH 3/3] Add "Group Identifier" support to virtio devices Venu Busireddy
2018-06-19 16:32 ` [Qemu-devel] [PATCH virtio 1/1] Add "Group Identifier" support to virtio PCI capabilities Venu Busireddy
2018-06-19 17:30 ` Michael S. Tsirkin
2018-06-19 17:54 ` Venu Busireddy [this message]
2018-06-19 18:12 ` [Qemu-devel] [virtio-dev] " Michael S. Tsirkin
2018-06-19 18:18 ` Venu Busireddy
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=20180619175406.GA14192@lt \
--to=venu.busireddy@oracle.com \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).