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

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

On 6/30/2023 12:47 AM, Parav Pandit wrote:
> > 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.
IMHO we should prevent modification through AQ after assigning a VF the 
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.
Not sure, without AQ, current live migration solution still migrates 
MSIX through the MSIX cap config space before
assigning the device to a guest.

And still, need to prevent modification through AQ after passthrough the 
device to a guest
> This is different discussion to do when SIOV R2 comes in place, the spec is under WIP so no point in debating for now.
so TRUE, however the core concept of SIOV is constant in R2 till now.

Let's discuss the details and decide how to prevent potential issues and 
how to reuse the cmds in my rebasing series.
>   
> > 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.
There are some buggy hypervisors, don't trust them. Lets discuss the 
details in my rebasing series.
> > > > > > 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.
There is still a slight different, for SRIOV passthrough, vfio or vDPA 
owns the device as well as its config space, but AQ is a side channel as
we discussed before, so we must pick the command set that can be reused 
in SRIOV carefully. I will try

Thanks