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

[Parav Pandit <parav@nvidia.com>]

> 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.
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 */
};