OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

On 10/30/2023 7:34 PM, Michael S. Tsirkin wrote:
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.
I agree, pass-through is clear and I don't think this worth arguing.

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]