On Wed, Oct 27 2021, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Wed, Oct 27, 2021 at 01:05:20PM -0600, Alex Williamson wrote: >> We're tossing around solutions that involve extensions, if not >> changes to the uAPI. It's Wednesday of rc7. > > The P2P issue is seperate, and as I keep saying, unless you want to > block support for any HW that does not have freeze&queice userspace > must be aware of this ability and it is logical to design it as an > extension from where we are now. I think the very fact that we're still discussing whether something needs to be changed/documented or not already shows that this is nothing that should go in right now. Actually, I'd already consider it too late even if we agreed now; I would expect a change like this to get at least two weeks in linux-next before the merge window. >> > The "don't-break-userspace" is not an absolute prohibition, Linus has >> > been very clear this limitation is about direct, ideally demonstrable, >> > breakage to actually deployed software. >> >> And if we introduce an open driver that unblocks QEMU support to become >> non-experimental, I think that's where we stand. > > Yes, if qemu becomes deployed, but our testing shows qemu support > needs a lot of work before it is deployable, so that doesn't seem to > be an immediate risk. Do you have any patches/problem reports you can share? If you already identified that there is work to be done in QEMU, I think that speaks even more for delaying this. What if we notice that uapi changes are needed while fixing QEMU?
