From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-comment-return-778-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Date: Wed, 3 Jul 2019 15:04:42 +0200 From: Cornelia Huck Message-ID: <20190703150442.43b85b87.cohuck@redhat.com> In-Reply-To: <20190628133614.GF2922@work-vm> References: <20190627192830.5285-1-dgilbert@redhat.com> <20190627192830.5285-3-dgilbert@redhat.com> <20190628120018.2bc8c387.cohuck@redhat.com> <20190628133614.GF2922@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [virtio-comment] Re: [virtio-dev] Re: [PATCH v5 2/5] pci: Define id field To: "Dr. David Alan Gilbert" Cc: virtio-dev@lists.oasis-open.org, virtio-comment@lists.oasis-open.org, stefanha@redhat.com, vgoyal@redhat.com List-ID: On Fri, 28 Jun 2019 14:36:14 +0100 "Dr. David Alan Gilbert" wrote: > * Cornelia Huck (cohuck@redhat.com) wrote: > > 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? > > Yes it is; this comes from moving it from the new structure we had it in > the previous version, into the main _cap. > > Can I just say that only some devices use it, or do I need something > more? Can I assume that 'id' is 0 for existing devices or is it > undefined? Maybe something like the following? "Used by some device types to uniquely identify multiple capabilities of a certain type. If the device type does not specify the meaning of this field, its contents are undefined." We should not make any assumptions here, I think. > > > > + 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). > > One way I was thinking was to say that the hierarchy now applies to > pairs of {cfg_type, id} rather than just cfg_type; but that depends on > the answer to the previous question to avoid breaking any existing > hierarchies. If we make the meaning of id device type specific, we also need to make its effects on the ordering device type specific. What about keeping the hierarchy, but specifying that a device type may override it if it specifies usage of the id field? Each device type using id would need to explicitly specify the ordering in that case. 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/