Re: [PATCH v7 1/1] vfio/nvgpu: Add vfio pci variant module for grace hopper

[Jason Gunthorpe]

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