public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Ankit Agrawal <ankita@nvidia.com>,
	Yishai Hadas <yishaih@nvidia.com>,
	"shameerali.kolothum.thodi@huawei.com" 
	<shameerali.kolothum.thodi@huawei.com>,
	"kevin.tian@intel.com" <kevin.tian@intel.com>,
	Aniket Agashe <aniketa@nvidia.com>, Neo Jia <cjia@nvidia.com>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	"Tarun Gupta (SW-GPU)" <targupta@nvidia.com>,
	Vikram Sethi <vsethi@nvidia.com>,
	Andy Currid <acurrid@nvidia.com>,
	Alistair Popple <apopple@nvidia.com>,
	John Hubbard <jhubbard@nvidia.com>,
	Dan Williams <danw@nvidia.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	David Airlie <airlied@redhat.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH v7 1/1] vfio/nvgpu: Add vfio pci variant module for grace hopper
Date: Thu, 31 Aug 2023 21:44:13 -0300	[thread overview]
Message-ID: <ZPEz3fy78wFvRuCB@nvidia.com> (raw)
In-Reply-To: <20230831122150.2b97511b.alex.williamson@redhat.com>

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

  reply	other threads:[~2023-09-01  0:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-22 20:23 [PATCH v7 1/1] vfio/nvgpu: Add vfio pci variant module for grace hopper ankita
2023-08-22 22:29 ` Alex Williamson
2023-08-23 13:56 ` Jason Gunthorpe
2023-08-23 14:18   ` Ankit Agrawal
2023-08-23 14:25     ` Jason Gunthorpe
2023-08-23 14:26     ` Alex Williamson
2023-08-23 14:50   ` Ankit Agrawal
2023-08-23 15:14     ` Alex Williamson
2023-08-23 15:16       ` Jason Gunthorpe
2023-08-23 15:24         ` Alex Williamson
2023-08-30 13:50 ` Christoph Hellwig
2023-08-30 15:39   ` Jason Gunthorpe
2023-08-31 12:26     ` Christoph Hellwig
2023-08-31 13:51       ` Ankit Agrawal
2023-08-31 14:04         ` Christoph Hellwig
2023-08-31 18:21           ` Alex Williamson
2023-09-01  0:44             ` Jason Gunthorpe [this message]
2023-09-01  5:48               ` Christoph Hellwig
2023-09-01  5:47             ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZPEz3fy78wFvRuCB@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=acurrid@nvidia.com \
    --cc=airlied@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=aniketa@nvidia.com \
    --cc=ankita@nvidia.com \
    --cc=apopple@nvidia.com \
    --cc=cjia@nvidia.com \
    --cc=daniel@ffwll.ch \
    --cc=danw@nvidia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jhubbard@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=targupta@nvidia.com \
    --cc=vsethi@nvidia.com \
    --cc=yishaih@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox