RE: [virtio-comment] Re: virtio member device provisioning get/set and virtio child device life cycle mixing not needed

[Parav Pandit <parav@nvidia.com>]

> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> Sent: Wednesday, June 28, 2023 10:18 PM


> > So msix provisioning via AQ is fine. VF can expose new MSIX capability post
> reconfiguration via AQ.
> It is the guest to config MSIX of an assigned VF by writing to MSIX capability.
> However host owns the AQ, means host can modify the MSIX config even when
> guest operational running.

Host can do many things not just MSIX config.
Host is not supposed modify the config.

In some OS MSI-X actual values are not even written by the guest...

> A new synchronization mechanism? Trap accesses to MSIX cap? Ban access of
> MSIX through AQ after DRIVER_OK?
> Do you have any detailed information about how to prevent the conflicts like
> this?

A hypervisor is a trusted entity to not mess with the VF.
A hypervisor can go to an extreme to even do PCI FLR while guest is running..

So no need to go to the extreme.

When hypervisor is untrusted in relatively far future, when a VF is put in some secure enclave and locked hypervisor will not such access.
At that point large part will be covered.