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] [PATCH v1 1/8] admin: Add theory of operation for device migration

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Friday, October 13, 2023 5:22 PM

> I know much more than 2.
> There are as many approaches as hypervisor implementations.
> > 1. Passthrough a virtio member device to guest Only PCI config space
> > and MSI-X table is trapped.
> > MSI-X table is also trapped due to a cpu/platform limitation. I will not go in
> that detail for a moment.
> > All the rest of the virtio member device interface is passthrough to the guest.
> > This includes,
> > (a) virtio common config space
> > (b) virtio device specific config space
> > (c) cvq if present
> > (d) io vqs and more vqs
> > (e) any shared memory
> > (f) any new construct that arise in coming years
> >
> > If one wants to do nesting, the member device should support nesting and it
> will be still able to do to next level.
> > To my knowledge, most cpus support single level nesting, that is VMM and
> VM.
> > Any higher-level nesting involves good amount of emulation in privileged
> operations.
> >
> > If virtio to do even more efficient than rest of the platform, I propose that
> member device can support nesting, so VMM->VM_L1 and VM_L1->VM_L2
> constructs are same.
> > This gives the best of both. Nesting support and passthrough both.
> > And since its layered approach, it naturally works for nested case.
> >
> > 2. Data path accelerated in device, rest all emulated.
> > This method make sense when underlying device is not a native virtio device.
> >
> > But for some reason, ok, one wants to build the infrastructure, we can
> attempt to find common pieces between #1 and #2 methods.
> We can't just build new interfaces each time someone wants a slightly different
> point on the pass through/emulation curve.
> I feel this is an important point for TC members to agree on.

Right. Above two are most common (or least known to me that is in use) that has clear requirements and existing stack to integrate with.
So better to converge than keep opposing #1.

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