Am Fr., 27. Feb. 2026 um 10:59 Uhr schrieb Klaus Jensen <[email protected]>: > > On Feb 17 16:25, Alexander Mikhalitsyn wrote: > > From: Alexander Mikhalitsyn <[email protected]> > > > > Dear friends, > > > > This patchset adds basic live migration support for > > QEMU emulated NVMe device. > > > > Implementation has some limitations: > > - only one NVMe namespace is supported > > - SMART counters are not preserved > > - CMB is not supported > > - PMR is not supported > > - SPDM is not supported > > - SR-IOV is not supported > > - AERs are not fully supported > > > > I believe this is something I can support in next patchset versions or > > separately on-demand (when usecase appears). But I wanted to share this > > first version as RFC to get some feedback on this in case if I'm approaching > > it wrong. > > > > Hi Alex, > > Nice work! > > As you have already identified, there are a lot of features that are > non-trivial to implement migration for. I am completely in favor of only > supporting migration on a very limited feature set (i.e., don't worry > about CMB, PMR, SPDM, SR-IOV, ZNS/FDP and so on). Focus on the bare > mandatory requirements. It would be preferable if the "is migration > possible?" test is an allowlist instead of a denylist. That makes sure > we don't add a feature down the road and forget to add it to the > denylist. I'm not 100% sure how to go about that at this point. > > AERs are something we need to deal with. We should not drop events. I > don't think I have a problem with aborting enqueued AERs, but not the > events. > > Finally, this at a minimum needs somekind of simple smoke test to catch > regressions. Preferably as part of the QEMU test suite itself, but if > that is hard to achieve, then I may be ok with an out-of-tree test that > maintainers can use.
Hi Klaus, JFYI: I've just sent a version 4 of this patchset, it has all the requested changes: - AERs handling - new autotest - better feature filtering Kind regards, Alex > > > Cheers, > Klaus
