From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-comment-return-773-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Date: Fri, 28 Jun 2019 12:00:18 +0200 From: Cornelia Huck Message-ID: <20190628120018.2bc8c387.cohuck@redhat.com> In-Reply-To: <20190627192830.5285-3-dgilbert@redhat.com> References: <20190627192830.5285-1-dgilbert@redhat.com> <20190627192830.5285-3-dgilbert@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [virtio-comment] Re: [PATCH v5 2/5] pci: Define id field To: "Dr. David Alan Gilbert (git)" Cc: virtio-dev@lists.oasis-open.org, virtio-comment@lists.oasis-open.org, stefanha@redhat.com, vgoyal@redhat.com List-ID: On Thu, 27 Jun 2019 20:28:27 +0100 "Dr. David Alan Gilbert (git)" wrote: > From: "Dr. David Alan Gilbert" > > For the virtio-fs device we require multiple large shared memory > regions. Differentiate these by an 'id' field in the base capability. > > Signed-off-by: Dr. David Alan Gilbert > --- > content.tex | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/content.tex b/content.tex > index 6433226..41926c0 100644 > --- a/content.tex > +++ b/content.tex > @@ -651,7 +651,8 @@ \subsection{Virtio Structure PCI Capabilities}\label{sec:Virtio Transport Option > u8 cap_len; /* Generic PCI field: capability length */ > u8 cfg_type; /* Identifies the structure. */ > u8 bar; /* Where to find it. */ > - u8 padding[3]; /* Pad to full dword. */ > + u8 id; /* Multiple capabilities of the same type */ > + u8 padding[2]; /* Pad to full dword. */ > le32 offset; /* Offset within bar. */ > le32 length; /* Length of the structure, in bytes. */ > }; > @@ -716,6 +717,11 @@ \subsection{Virtio Structure PCI Capabilities}\label{sec:Virtio Transport Option > > Any other value is reserved for future use. > > +\item[\field{id}] > + Multiple capabilities of the same type can exist as long > + as they each have a unique \field{id}. The specific The requirement for id is new, isn't it? Shouldn't it rather be optional? > + meaning of the field is different for each device type. > + > \item[\field{offset}] > indicates where the structure begins relative to the base address associated > with the BAR. The alignment requirements of \field{offset} are indicated The current specification for cfg_type defines a kind of hierarchy for capabilities of the same type (first one is preferred). We probably need to be more explicit how id may interact with that (even if it is device type specific). 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/