Re: [RFC PATCH 5/5] nvme-vfio: Add a document for the NVMe device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 12/6/2022 5:01 PM, Christoph Hellwig wrote:
On Tue, Dec 06, 2022 at 10:48:22AM -0400, Jason Gunthorpe wrote:
Sadly in Linux we don't have a SRIOV VF lifecycle model that is any
use.
Beward:  The secondary function might as well be a physical function
as well.  In fact one of the major customers for "smart" multifunction
nvme devices prefers multi-PF devices over SR-IOV VFs. (and all the
symmetric dual ported devices are multi-PF as well).

So this isn't really about a VF live cycle, but how to manage life
migration, especially on the receive / restore side.  And restoring
the entire controller state is extremely invasive and can't be done
on a controller that is in any classic form live.  In fact a lot
of the state is subsystem-wide, so without some kind of virtualization
of the subsystem it is impossible to actually restore the state.

ohh, great !

I read this subsystem virtualization proposal of yours after I sent my proposal for subsystem virtualization in patch 1/5 thread.
I guess this means that this is the right way to go.
Lets continue brainstorming this idea. I think this can be the way to migrate NVMe controllers in a standard way.


To cycle back to the hardware that is posted here, I'm really confused
how it actually has any chance to work and no one has even tried
to explain how it is supposed to work.

I guess in vendor specific implementation you can assume some things that we are discussing now for making it as a standard.





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux