RE: [virtio-comment] Re: [PATCH v1 3/8] device-context: Define the device context fields for device migration

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Monday, October 30, 2023 5:05 PM
> 
> On Mon, Oct 30, 2023 at 10:23:14AM +0000, Parav Pandit wrote:
> > > And the helper driver could be considered as a part of the
> > > hypervisor, or the guest vCPU can not access the host side devices.
> > >
> > > For example, the path is hw-->vfio_pci-->qemu-->guest. IT IS NOT hw--
> >guest.
> 
> I think above makes sense. Nvidia decided to standardize on VFIO and that's ok,
> but there's no point in calling specifically VFIO "true passthrough" or whatever
> the marketing term du jour is. This is not a VFIO TC here. I do wish one of the
> sides in this discussion stopped promoting their architecture and the one true
> way and tried to actually build interfaces addressing multiple architectures,
> though. Otherwise we'll keep getting stuck.
> 
There are more than Nvidia here.
And yes, for sure I am not promoting vfio_only use case.
From beginning it is listed as one use case as member device and owner device follow the same virtio access interface being present in guest or hypervisor etc.

> > In virtio spec we only talk about the driver, and the device in context of
> passthrough device.
> > So for virtio common config, dev config, cvq, data vqs are guest driver ->
> device.
> > There is no other entity inbetween.
> 
> No longer true - with admin commands we have 2 devices: owner and member,
> and each has its own driver.
Sure, when describing the config space access, cvq, data vq we don't introduce the term as owner and device,
Because from spec and device point of view, it's the driver accessing it.

Only the admin commands or group commands talk about owner and member drivers.