Re: [PATCH 1/9] vfio: Make vfio_(un)register_notifier accept a vfio_device

From: Jason Gunthorpe <jgg@nvidia.com>
To: "Wang, Zhi A" <zhi.a.wang@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	David Airlie <airlied@linux.ie>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	Vineeth Vijayan <vneethv@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Christoph Hellwig <hch@lst.de>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	Jason Herne <jjherne@linux.ibm.com>,
	Eric Farman <farman@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Harald Freudenberger <freude@linux.ibm.com>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
	"intel-gvt-dev@lists.freedesktop.org"
	<intel-gvt-dev@lists.freedesktop.org>,
	Tony Krowiak <akrowiak@linux.ibm.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Peter Oberparleiter <oberpar@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>
Subject: Re: [PATCH 1/9] vfio: Make vfio_(un)register_notifier accept a vfio_device
Date: Wed, 13 Apr 2022 17:04:18 -0300	[thread overview]
Message-ID: <20220413200418.GX2120790@nvidia.com> (raw)
In-Reply-To: <661447fd-b041-c08d-cedc-341b31c405f8@intel.com>

On Wed, Apr 13, 2022 at 07:17:52PM +0000, Wang, Zhi A wrote:
> On 4/13/22 5:37 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 13, 2022 at 06:29:46PM +0200, Christoph Hellwig wrote:
> >> On Wed, Apr 13, 2022 at 01:18:14PM -0300, Jason Gunthorpe wrote:
> >>> Yeah, I was thinking about that too, but on the other hand I think it
> >>> is completely wrong that gvt requires kvm at all. A vfio_device is not
> >>> supposed to be tightly linked to KVM - the only exception possibly
> >>> being s390..
> >>
> >> So i915/gvt uses it for:
> >>
> >>  - poking into the KVM GFN translations
> >>  - using the KVM page track notifier
> >>
> >> No idea how these could be solved in a more generic way.
> > 
> > TBH I'm not sure how any of this works fully correctly..
> > 
> > I see this code getting something it calls a GFN and then passing
> > them to vfio - which makes no sense. Either a value is a GFN - the
> > physical memory address of the VM, or it is an IOVA. VFIO only takes
> > in IOVA and kvm only takes in GFN. So these are probably IOVAs really..
> > 
> Can you let me know the place? So that I can take a look.

Well, for instance:

static int gvt_pin_guest_page(struct intel_vgpu *vgpu, unsigned long gfn,
		unsigned long size, struct page **page)

There is no way that is a GFN, it is an IOVA.

> > It seems the purpose is to shadow a page table, and it is capturing
> > user space CPU writes to this page table memory I guess?
> > 
> Yes.The shadow page will be built according to the guest GPU page table.
> When a guest workload is executed in the GPU, the root pointer of the
> shadow page table in the shadow GPU context is used. If the host enables
> the IOMMU, the pages used by the shadow page table needs to be mapped as
> IOVA, and the PFNs in the shadow entries are IOVAs.

So if the page table in the guest has IOVA addreses then why can you
use them as GFNs?

Or is it that only the page table levels themselves are GFNs and the
actual DMA's are IOVA? The unclear mixing of GFN as IOVA in the code
makes it inscrutible.

Jason