[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y49fjFD6foGorhmp@ziepe.ca>
Date: Tue, 6 Dec 2022 11:28:12 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Christoph Hellwig <hch@....de>
Cc: Lei Rao <lei.rao@...el.com>, kbusch@...nel.org, axboe@...com,
kch@...dia.com, sagi@...mberg.me, alex.williamson@...hat.com,
cohuck@...hat.com, yishaih@...dia.com,
shameerali.kolothum.thodi@...wei.com, kevin.tian@...el.com,
mjrosato@...ux.ibm.com, linux-kernel@...r.kernel.org,
linux-nvme@...ts.infradead.org, kvm@...r.kernel.org,
eddie.dong@...el.com, yadong.li@...el.com, yi.l.liu@...el.com,
Konrad.wilk@...cle.com, stephen@...eticom.com, hang.yuan@...el.com
Subject: Re: [RFC PATCH 5/5] nvme-vfio: Add a document for the NVMe device
On Tue, Dec 06, 2022 at 04:01:31PM +0100, Christoph Hellwig wrote:
> 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.
I cannot speak to nvme, but for mlx5 the VF is laregly a contained
unit so we just replace the whole thing.
>From the PF there is some observability, eg the VF's MAC address is
visible and a few other things. So the PF has to re-synchronize after
the migration to get those things aligned.
> 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'm interested as well, my mental model goes as far as mlx5 and
hisillicon, so if nvme prevents the VFs from being contained units, it
is a really big deviation from VFIO's migration design..
Jason
Powered by blists - more mailing lists