RE: RE: [virtio-comment] Re: [virtio-dev] Re: [virtio-comment] [RFC PATCH] admin-queue: bind the group member to the device

[Parav Pandit <parav@nvidia.com>]

> From: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Sent: Monday, June 26, 2023 8:33 AM

[..]

> > The flow is for one OS (Linux) is:
> > 1. user enable SR-IOV on the PF device in a host, which creates SR-IOV VFs in
> the device.
> > (num_vfs and vf enable bit in the PCI capability)
> >
> > 2. VFs are created at the PCI level in the host system and also inside
> > the device
> >
> > 3. A user on the host may bind these VFs to the VF driver
> > (virtionet/blk or vfio or vp_vdpa or some other)
> >
> > Between step #2 and #3, a user may configure one or multiple attributes of
> the VF.
> > This includes feature bits, config space fields, vf msix vectors and more.
> > This is to be using admin command.
> > These admin commands definition is due.
> 
> 
> YES
> 
> My problem is that the nic is created by user on the management platform.  Or
> the device is migrated from other host.
>
Do you mean the management platform != the owner PF device?

 
> So we need to bind the device(created by user) to the vf between step #2 and
> #3.
>
We likely have some terminology issues.
Bind the device to the vf?

At OS level, there are
a. virtio PCI PF owner device
b. virtio PCI VF member device

c. some OS level device (such as net/blk, vfio, vdpa created by attaching #b to the driver)

d. An optional representor device on the DPU side (defined and managed by the vendor, outside the virtio spec as device implemtion).
Is this #d you call management platform?
If so, yes, orchestration may need to consult management platform, but this is optional.