On Wed, 19 Jan 2022 12:38:21 -0400 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Wed, Jan 19, 2022 at 09:06:14AM -0700, Alex Williamson wrote: > > On Wed, 19 Jan 2022 11:40:28 -0400 > > Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > > > > On Wed, Jan 19, 2022 at 08:32:22AM -0700, Alex Williamson wrote: > > > > > > > If the order was to propose a new FSM uAPI compatible to the existing > > > > bit definitions without the P2P states, then add a new ioctl and P2P > > > > states, and require userspace to use the ioctl to validate support for > > > > those new P2P states, I might be able to swallow that. > > > > > > That is what this achieves! > > > > > > Are you really asking that we have to redo all the docs/etc again just > > > to split them slightly differently into patches? What benefit is this > > > make work to anyone? > > > > Only if you're really set on trying to claim compatibility with the > > existing migration sub-type. The simpler solution is to roll the > > arc-supported ioctl into this proposal, bump the sub-type to v2 and > > How about we just order the arc-supported ioctl patch first, then the > spec revision and include the language about how to use arc-supported > that is currently in the arc-supported ioctl? > > I'm still completely mystified why you think we need to bump the > sub-type at all?? > > If you insist, but I'd like a good reason because I know it is going > to hurt a bunch of people out there. ie can you point at something > that is actually practically incompatible? I'm equally as mystified who is going to break by bumping the sub-type. QEMU support is experimental and does not properly handle multiple devices. I'm only aware of one proprietary driver that includes migration code, but afaik it's not supported due to the status of QEMU. Using a new sub-type allows us an opportunity to update QEMU to fully support this new uAPI without any baggage to maintain support for the v1 uAPI or risk breaking unknown users. Minimally QEMU support needs to be marked non-experimental before I feel like we're really going to "hurt a bunch of people", so it really ought not to be an issue to revise support to the new uAPI at the same time. If a hypervisor vendor has chosen to run with experimental QEMU support, it's on them to handle long term support and a transition plan and I think that's also easier to do when it's clear whether the device is exposing the original migration uAPI or the updated FSM model with p2p states and an arc-supported ioctl. Thanks, Alex
