On Thu, Feb 17, 2022 at 10:15:54AM -0700, Alex Williamson wrote: > I feel obligated to ask, is PRE_COPY support essentially RFC at this > point since we have no proposed in-kernel users? Yes, it is included here because the kernel in v1 had PRE_COPY, so it seemed essential to show how this could continue to look to evaluate v2. NVIDIA has an out of tree driver that implemented PRE_COPY in the v1 protocol, and we have some future plan to use it in a in-tree driver. > It seems like we're winding down comments on the remainder of the > series and I feel ok with where it's headed and the options we have > available for future extensions. Thanks, it was a lot of work for everyone to get here! Yishai has all the revisions from Kevin included, he will sent it on Sunday. Based on this Leon will make a formal PR next week so it can go into linux-next through your tree. We have to stay co-ordinated with our netdev driver branch.. I will ping the acc team and make it priority to review their next vresion. Let's try to include their driver as well. We'll start to make a more review ready qemu series. > PS - Why is this a stand-alone ioctl rather than a DEVICE_FEATURE? You asked for the ioctl to be on the data_fd, so there is no DEVICE_FEATURE infrastructure and I think it doesn't make sense to put a multiplexor there. We have lots of ioctl numbers and don't want this to be complicated for performance. Thanks, Jason
