> From: Xuan Zhuo <[email protected]>
> Sent: Tuesday, June 27, 2023 10:21 PM
> > I can see this making sense as a feature bit that says VFs are not
> > initialized by default and must first be setup through an admin command.
> > This will likely need to be a feature bit because it's changing
> > behaviour outside of admin commands.
> >
> > Then, we can have:
> >
> > ADMIN_SETUP VF#
> > ADMIN_CLEANUP VF#
> >
> > I like this because this generalizes CREATE/DESTROY that SIOV guys proposed.
>
What does this command actually do or expected do on the device?
> Great!!
>
> >
> >
> > Why do we need an id as a level of indirection though? What is wrong
> > with just using VF# directly?
>
> I think VF# is ok. I also need to use it. But we need an ID for virtio device
> not the
> transport(PF, VF).
>
> What I want to emphasize is that PCI(pf or vf) is a transport, it is only
> used to
> connect the virtio driver and the virtio device. Right?
>
> The virtio device does not necessarily exist depending on PCI. For example, a
> virtio device is migrated from another DPU, and it is not associated with any
> PCI.
> What I have always wanted to say is that this device(not PCI) must have its
> own
> ID, which has nothing to do with the transport.
>
A virtio device can have the id visible to self and visible to group owner
device.
> Now we want to use this migrated device and connect it to the corresponding
> vm (migrated from the same host). We can passthrough vf to this vm. But how
> do I tell our DPU to bind this migrated device with this vf?
When a virtio device state is set on a specific VF on the compute side (not on
the dpu side),
This directly indicates to the dpu side, which virtio device is attached to
which VF.
> We can specify the VF by the VF#, but how can we specify the virtio device?
> Maybe there are two migrated virtio device.
>
virtio device state setting itself will contain the device identifier.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
