[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 Thu, Nov 2, 2023 at 2:10âPM Parav Pandit <parav@nvidia.com> wrote: > > > > From: Jason Wang <jasowang@redhat.com> > > Sent: Thursday, November 2, 2023 9:54 AM > > > > On Wed, Nov 1, 2023 at 11:07âAM Parav Pandit <parav@nvidia.com> wrote: > > > > > > > > > > > > > From: Jason Wang <jasowang@redhat.com> > > > > Sent: Wednesday, November 1, 2023 6:03 AM > > > > > > > > On Tue, Oct 31, 2023 at 1:17âPM Parav Pandit <parav@nvidia.com> wrote: > > > > > > > > > > > > > > > > > > > > > From: virtio-comment@lists.oasis-open.org > > > > > > <virtio-comment@lists.oasis- open.org> On Behalf Of Jason Wang > > > > > > Sent: Tuesday, October 31, 2023 7:07 AM > > > > > > > > > > > > On Mon, Oct 30, 2023 at 12:28âPM Parav Pandit <parav@nvidia.com> > > wrote: > > > > > > > > > > > > > > > > > > > > > > From: Jason Wang <jasowang@redhat.com> > > > > > > > > Sent: Monday, October 30, 2023 9:35 AM > > > > > > > > > > > > > > > > å 2023/10/26 11:50, Parav Pandit åé: > > > > > > > > >> From: virtio-comment@lists.oasis-open.org > > > > > > > > >> <virtio-comment@lists.oasis- open.org> On Behalf Of Jason > > > > > > > > >> Wang For example, you still haven't succeeded in defining > > > > passthrough. > > > > > > > > > It was defined on 19th Oct in [1]. > > > > > > > > > What part is not clear to you in definition of passthrough device? > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://lore.kernel.org/virtio- > > > > > > > > comment/PH0PR12MB5481EA6A4D0C64C5AF6D3A > > > > > > > > > 57DCD4A@PH0PR12MB5481.namprd12.prod.outlook.com/ > > > > > > > > > > > > > > > > > > > > > > > > Let me copy-paste it again: > > > > > > > > > > > > > > > > For example, assuming you are correct, you still fail to > > > > > > > > explain > > > > > > > > > > > > > > > > 1) what is trapped and what's not, or what's the boundary > > > > > > > Passthrough definition was replied few times. > > > > > > > One of them is here, > > > > > > > https://lore.kernel.org/virtio- > > > > > > comment/PH0PR12MB5481EA6A4D0C64C5AF6D3A > > > > > > > 57DCD4A@PH0PR12MB5481.namprd12.prod.outlook.com/ > > > > > > > I donât know what you mean by 'explain'. What do you want to > > > > > > > be > > > > explained? > > > > > > > What is trapped is listed in > > > > > > > https://lore.kernel.org/virtio- > > > > > > comment/PH0PR12MB5481EA6A4D0C64C5AF6D3A > > > > > > > 57DCD4A@PH0PR12MB5481.namprd12.prod.outlook.com/ > > > > > > > What is not trapped is also listed in > > > > > > > https://lore.kernel.org/virtio- > > > > > > comment/PH0PR12MB5481EA6A4D0C64C5AF6D3A > > > > > > > 57DCD4A@PH0PR12MB5481.namprd12.prod.outlook.com/ > > > > > > > So what more do you want to explain in there? > > > > > > > > > > > > You explained that MSI-X is trapped but not the others. People > > > > > > may know > > > > why. > > > > > > or what's the boundary to choose to trap or not. > > > > > > > > > > > If a platform can support without trapping, it can be avoided as > > > > > well and can > > > > be added in the future. > > > > > > > > Who is going to do that synchronization? > > > Lets first bring that hypervisor sw design before discussing phantom problem > > solving. > > > All necessary modules will be involved in synchronization depending on how > > its done in future. > > > > 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. > 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. > > > > > > > > > > > > > > > > 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. > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]