On Tue, Feb 01 2022, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Tue, Feb 01, 2022 at 02:26:29PM +0100, Cornelia Huck wrote: > >> > We can certainly defer the kernels removal patch for a release if it >> > makes qemu's life easier? >> >> No, I'm only talking about the QEMU implementation (i.e. the code that >> uses the v1 definitions and exposes x-enable-migration). Any change in >> the headers needs to be done via a sync with upstream Linux. > > If we leave the v1 and v2 defs in the kernel header then qemu can sync > and do the trivial rename and keep going as-is. > > Then we can come with the patches to qemu update to v2, however that > looks. > > We'll clean the kernel header in the next cylce. I'm not sure we're talking about the same things here... My proposal is: - remove the current QEMU implementation of vfio migration for 7.0 (it's experimental, and if there's anybody experimenting with that, they can stay on 6.2) - continue with getting this proposal for the kernel into good shape, so that it can hopefully make the next merge window (- also continue to get the documentation into good shape) - have an RFC for QEMU that contains a provisional update of the relevant vfio headers so that we can discuss the QEMU side (and maybe shoot down any potential problems in the uapi before they are merged in the kernel) I don't think a "dual version header" would really help here. If we don't want to rip out the old QEMU implementation yet, I can certainly also live with that. We just need to be mindful once the changes hit Linus' tree, but it is quite likely that QEMU would be in freeze by then. As long as updating the headers leads to an obvious failure, it's managable (although the removal would still be my preferred approach.) Alex, what do you think?
