Re: [PATCH v3 1/4] Add virtio Admin virtqueue

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Feb 08, 2022 at 03:48:42PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, February 8, 2022 9:08 PM
> 
> 
> > On Tue, Feb 08, 2022 at 03:35:58PM +0000, Parav Pandit wrote:
> > >
> > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > Sent: Tuesday, February 8, 2022 8:56 PM
> > >
> > > > > I might have been a bit too vague about what I had been thinking
> > > > > about. Let's do a sketch (intentionally without concrete sizes):
> > > > >
> > > > > +-------------------------------------------------------+
> > > > > | command                                               |
> > > > > +-------------------------------------------------------+
> > > > > | target type (0 - self, 1 - dev id, 2 - group id, ...  |
> > > > > +-------------------------------------------------------+
> > > > > | dev id                                                |
> > > > > +-------------------------------------------------------+
> > > > > | group id                                              |
> > > > > +-------------------------------------------------------+
> > > > > | command-specific data                                 |
> > > > > +-------------------------------------------------------+
> > > > > | response part                                         |
> > > > > +-------------------------------------------------------+
> > > > >
> > > > > 'dev id' would be valid for 'target type' == 1, 'group id' would
> > > > > be valid for 'target type' == 2. Alternatively, 'dev id' and 'group id'
> > > > > could be a single 'target id' field; if there's nothing better to
> > > > > use, it can simply contain a uuid.
> > > >
> > > > I am not sure why do we have both dev id and group id.
> > > > They are never used together right?
> > > > Maybe just have an id length field if we can't agree on how much
> > > > space to reserve.
> > > This is what I propose in a previous email.
> > > A device id can be duplicate in different groups.
> > > So to build hierarchy group id will be desired.
> > >
> > > So id[] array can contain nested one or multiple fields.
> > 
> > I guess nesting is for when there's like an SF within a VF?
> That is one case, but I imagine that if SF is on top of VF, than VF will directly manage it. PF should not get involved in nested management.
> 
> Nesting is for the case, where there is explicit group. A simple example is,
> A NIC has two PCI functions, both support SR-IOV and VFs.
> But only one PF is managing the VFs for msix, mac etc configuration.

Or maybe that's the case of "it hurts when I do this - then don't do that".


> In this case there are two groups g0, g1.
> grp0 belongs to PF0.
> grp1 belongs to PF1.
> 
> So a id definition looks like below.
> 
> struct pf_identifier {
> 	u8 device; /* pci device of bdf */
> 	u8 function;	/* pci function of bdf */
> } __attribute__(packed);
> 
> struct pci_vf_grouped_id {
> 	struct pf_identifier pf_id;
> 	u16 vf_num;
> };
> 
> struct device_identfier {
> 	u8 id_type;	/* below id type enum */
> 	u16 id_len;
> 	union {
> 		u8 raw[0];
> 		struct pci_vf_grouped_id gvf_id;
> 	} id_data;	
> };
> 
> enum id_type {
> 	VIRTIO_PCI_VF = 0,	/* implicitly grouped VF */
> 	VIRTIO_PCI_REMOTE_VF = 1, /* part of hirechical group */
> 	VIRTIO_SF,
> 	VIRTIO_PCI_REMOTE_SF, /* part of hirechical group */
> 	VIRTIO_MMIO,
> 	/* more */
> };