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

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Monday, November 6, 2023 12:05 PM

[..]
> > > It's not the charge of the virtio spec to mandate any type of hypervisor
> design.
> > > But it looks to me you want to do that.
> > You always attribute is wrong to disregard the proposal which is incorrect.
> 
> This is not my point. I'm just saying, I never say any virtio existing facilities need
> to be synchronized with the development of the hypervisor. That's great proof
> that it is well designed.
> 
> If the proposal is designed in a general method without limitations, the spec can
> keep working like a charm in the past.
> 

The fact is there are at lest 3 hypervisors exists which has defined the live migration framework.
And virtio is adapting to it.

Defining something very generic without a known interface is mostly theoretical discussion.

> > Virtio spec does not mandate it.
> > Why?
> > Because virtio is so late in the cycle of developing features, that it has to fit
> into the existing hypervisors design to support the feature and proven UAPIs.
> >
> > So like RSS, flow filters, statistics, provisioning, and more, it is adding the
> support for UAPIs which are already present for a while across multiple devices.
> >
> > So attributing it as mandating is simply wrong.
> > It is addressing the existing use case.
> >
> > One can always build new hypervisor and demand new features from virtio.
> > That is perfectly fine.
> >
> > Your expectation is that device migration framework to work for an undefined
> hypervisor, which is just silly.
> 
> It's not silly, for example virtio was designed before VFIO was invented. If there's
> no layer violation and the spec aligns with PCI spec, we don't need to do any
> synchronization to say "we can support VFIO now".  And we never have a
> feature that claims to work under condition X,Y,Z in the past.
> 
With that theory, device migration should have worked without any patches that we are doing now. :)

> >
> > > > > > > >
> > > > > > > > > 2) if the hypervisor is not developed with those
> > > > > > > > > assumptions, things can work
> > > > > > > > What to explain in #2. :)
> > > > > > > > Things can expand when such hypervisor is born.
> > > > > > >
> > > > > > > So the point is still, to make your proposal to be useful in
> > > > > > > more use
> > > cases.
> > > > > > >
> > > > > > When a use case arise, device context can be expanded.
> > > > >
> > > > > It's not device context.
> > > > >
> > > > I donât see why not. It is stored in the device.
> > > > Remapping part will be hypervisor specific, so it may be stored in
> > > > platform
> > > specific migration data.
> > >
> > > The point is, device context should work for all type of hypervisors.
> > > You can't claim it can only work with your "passthrough" model.
> > >
> > Which other type you specifically have in mind?
> > The current proposal should work for:
> > 1. passthrough model
> > 2. may be for vdpa model.
> 
> Note that, it's not the vdpa model, it's the model that can do conditional traps
> for virtio config.
> 
> I think we are somehow making an agreement here, we need to make sure the
> proposal works in both modes.
> 
> Then I'm fine.
> 
Ok. So lets extend the admin commands that fits the both the models.
I did for #1, you should see which of those can be useful for #2 or it needs new commands or cmd extensions.

> > The model seems to work for passthrough and vdpa both cases to me.
> >
> > If something is missing for #2, either device context can be updated, or new
> commands can be added.
> >
> > > >
> > > > > > No point in making things no one implements or not present in
> hypervisor.
> > > > > > The infrastructure is extendible so spec is covered for it.
> > > > >
> > > > > It would be problematic if you stick to claim "passthrough" but not.
> > > >
> > > > I donât know what this means. I am not debating passthrough/non-
> > > passthrough.
> > > > What is inside the device, will be part of device-context.
> > > > What is part of the platform content, will be part of platform context.
> > > > Since this is generic to all types of PCI devices, I donât see a
> > > > need to over-solve
> > > it now in virtio.
> > >
> > > Ok, so you agree it can work even if hypervisor want to trap?
> >
> > Yes. I believe so, it can work.
> > If something is missing, we should discuss to enhance it.
> 
> That's great.
> 
> Thanks