On Thu, Aug 31, 2023 at 12:21:50PM -0600, Alex Williamson wrote: > I assume the above driver understands how to access and make use of > this coherent memory whether running bare-metal or virtualized, so > potentially we have some understanding of how it's used by the driver, > which can't be said for all devices used with vfio. I'm therefore not > sure how we can suddenly decide to impose a mainline driver requirement > for exposing a device to userspace. Thanks, Yeah, I was comfortable with removing the old powernv VFIO stuff based on the combined logic that the platform was dead, powernv has weird arch entanglements and there was no open source driver anyhow so maintaining the mess past the vendor lifetime was looking bad. This has none of those issues. I think the threshold here should be the maintainability of the kernel and its associated open ecosystem. An open source qemu, and a open source VM kernel driver is a pretty good situation to sustain this driver. In particular if Alex&co think the qemu side should not advance then this should not be merged. For comparison, I'm much more unhappy about VFIO_UPDATE_VADDR from a maintainability perspective than I am about this. There was a half hearted effort to get the userspace side in qemu and now we are now stuck with an ugly kernel side mess with no open source userspace so we can't even test. :\ Considering the vigorous objections when I tried to remove it I assume a cloud operator is running it with a proprietary userspace. Certainly I would strongly support removing kernel side parts if the qemu side doesn't get merged within a year or something like that. Jason
