Messages in this thread |  | | Date | Sun, 11 Dec 2022 14:05:04 +0200 | Subject | Re: [RFC PATCH 5/5] nvme-vfio: Add a document for the NVMe device | From | Max Gurtovoy <> |
| |
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.
|  |