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: Thursday, June 29, 2023 2:36 AM

> > I mean querying and provisioning feature bits and config space fields is the
> basic functionality before attempting to securing it.
> It may be fine to _ONLY_ provision virtio configuration through AQ, limit the
> changes in virtio spec.
> Actually this is not provisioning a VF, this is modification after creation, because
> we still create a VF through PCI interface num_vfs.

It is a modification before a VF is given to the guest.

> > I was told that you are going to rebase the tvq series on top of AQ, hence the
> ask to split the series to two.
> > If I misunderstood, its fine, my bad.
> > Someone else will pick up the features/config provisioning+query part.
> If you want to re-use some transport cmds for SRIOV, that's fine, we just can not
> reuse the whole command set for SRIOV.
Sure.

> For example, we expect AQ as a transport for SIOV, therefore MSIX is config-ed
> through AQ, as we discussed this set_msix_cmd may not apply to SRIOV for
> now.
>
MSIX provisioning for SIOV and SRIOV applies through the AQ.
Configuring the MSIX entry itself by the device is not through the AQ, it must a direct channel without mediation.
This is different discussion to do when SIOV R2 comes in place, the spec is under WIP so no point in debating for now.
 
> Querying is fine as you know it is read only.
> For setting, I assume we need a new mechanism to sycn the PCI config space
> with AQ, and still the host owns the AQ.
> 
There is no good reason establish for this need. So I donât the point of only asserting. :)
Hypervisor sw already takes care to not mess and VFs given to the VM and does not touch it.
Hence, I donât see a need for over engineering here.
Once there is solid race condition explained that requires sync, it is better to do that time.

> >
> >>>> I still think we should resolve the issues first.
> >>> I donât think this is really an issue.
> >>> Passthrough VF devices are already there for more than a decade and
> >>> msix
> >> config is just one small piece of it to provision, among others.
> >> passthrough, like vfio which assign the device including its config
> >> space to a guest, works well. While AQ is a side channel.
> > Sure. AQ is side channel but hypervisor's ability to access VF while in use
> including doing FLR and more is already exist.
> a hypervisor should not reset anything when the device has been
> passthroughed, or such a hypervisor may be considered buggy
> > So such thing does not need special spec level protection.
> > An OS driver can handle it internally.
> again, I wish we don't introduce more attacking surface even the stack is already
> vulnerable.
There is no attack surface added. It is withing the hypervisor boundary owned by the owner device driver.
How to access a owner driver is role of hypervisor OS like how its done today for virtio and non virtio devices, not really the virtio spec.