Are you okay to live without this ioctl for now? I think QEMU is the one that needs to be fixed and will have to be made legacy guest aware. I think the kernel can just honor the feature negotiation result done by QEMU and do as what's told to.Will you agree?
If it's fine, I would proceed to reverting commit fe36cbe067 and related code in question from the kernel.
Thanks,
-Siwei
On 2/24/2021 10:24 AM, Si-Wei Liu
wrote:
Detecting it isn't enough though, we will need a new ioctl to notifyWell, although I think adding an ioctl is doable, may I know what the use case there will be for kernel to leverage such info directly? Is there a case QEMU can't do with dedicate ioctls later if there's indeed differentiation (legacy v.s. modern) needed?
the kernel that it's a legacy guest. Ugh :(
One of the reason I asked is if this ioctl becomes a mandate for vhost-vdpa kernel. QEMU would reject initialize vhost-vdpa if doesn't see this ioctl coming?
If it's optional, suppose the kernel may need it only when it becomes necessary?
Thanks,
-Siwei
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
