Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     "ankita@nvidia.com" <ankita@nvidia.com>,
        "jgg@nvidia.com" <jgg@nvidia.com>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "yishaih@nvidia.com" <yishaih@nvidia.com>,
        "shameerali.kolothum.thodi@huawei.com" 
        <shameerali.kolothum.thodi@huawei.com>
CC:     "aniketa@nvidia.com" <aniketa@nvidia.com>,
        "cjia@nvidia.com" <cjia@nvidia.com>,
        "kwankhede@nvidia.com" <kwankhede@nvidia.com>,
        "targupta@nvidia.com" <targupta@nvidia.com>,
        "vsethi@nvidia.com" <vsethi@nvidia.com>,
        "Currid, Andy" <acurrid@nvidia.com>,
        "apopple@nvidia.com" <apopple@nvidia.com>,
        "jhubbard@nvidia.com" <jhubbard@nvidia.com>,
        "danw@nvidia.com" <danw@nvidia.com>,
        "anuaggarwal@nvidia.com" <anuaggarwal@nvidia.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v10 1/1] vfio/nvgpu: Add vfio pci variant module for grace
 hopper
Thread-Topic: [PATCH v10 1/1] vfio/nvgpu: Add vfio pci variant module for
 grace hopper
Thread-Index: AQHZ53/9zWvTaIde6US2fOptfhuD4LAv1HCA
Date:   Thu, 28 Sep 2023 06:33:09 +0000
Message-ID: <BN9PR11MB52761E49534852AE98C25B458CC1A@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20230915025415.6762-1-ankita@nvidia.com>
In-Reply-To: <20230915025415.6762-1-ankita@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?uLtwpuXUlTGjdYJQhNe+bPDeujpUe33tnJF4Xs7IgJiTnCeEGnBVPPwIzOc9?=
 =?us-ascii?Q?H9FhAWTGkORzvzUoEUBjvjGDkCecS927EMDgPMfn0R50uYr4SW5UVHdVmBeD?=
 =?us-ascii?Q?BVlCbW2Qvbr3DkWPT8/WlxOz2nrGdyCIpJ3eVMWw4ug/RoHYRQfc2o99Ok9O?=
 =?us-ascii?Q?SgxCmF3mjzCe5r7koV2GKjX1rc5J2+B2qkYXxy6synU460HTTtFEhJfWvBxQ?=
 =?us-ascii?Q?S0oJe32UheeRZv3M/xe5buD2SBEL3R9Jf5mw+mtVJuZXbiZ1VVDd8IdxUm1S?=
 =?us-ascii?Q?oaj/uk29rdANDHuwcETTXf2xONTsvLpFFt1RMvMfvJulDGUfVS3irbnm5pSa?=
 =?us-ascii?Q?HpMlDFCsxEX1EcdOx20mwkhiZ6KAXfUz3Ak7oHQ3ATPJzggU6RFLLqFM8ICn?=
 =?us-ascii?Q?eGwWvA5XDhYBZfOGHI1UEFj4xNm8gdqCxSXXJ6QE/nS4dEcU3Ql8944IhOlC?=
 =?us-ascii?Q?uCKTEGNXONKeG6at9E9VNQTna1AL52mrgtudLxgh/SgHcwUWgsUyjVma61Wd?=
 =?us-ascii?Q?dSX49nM70K9p+V99w9zaAe02Ljy7q5Roh7E1mu3UoE44T6ii76rSWUVLyexM?=
 =?us-ascii?Q?DUGGoALGopM3knaiIxe9hUkSLREvvzTdDJsBUtiW0xDf0wr2hH4PnttorIgQ?=
 =?us-ascii?Q?8PCcBVZfkd9+fsV2kV63MFFZ17l+UqEBcDQjwUl00L9loWjeoj/6+ZQA9OdD?=
 =?us-ascii?Q?EGdvUmy7WwzYKqb+jwQHaobxDi0M6+kZWnBR4vstc/tdBaWs64H7egrM7pC3?=
 =?us-ascii?Q?IpP2tdyaeXoOv5Yvt5ePQSaaf47Z5TqN59f2m7sCxM2RgMY7w4okxpoKgQof?=
 =?us-ascii?Q?5ZapiZhaMAbKr+ThuuBee/YHIt+VUfbMwvRW3c3MBQw2hKJkhsWGl71r8Yus?=
 =?us-ascii?Q?IwGYWNIforIV91HfocBRZgbElOJfjat/v/KRnvPjuh8MrNkoMXzPCdoAeI1m?=
 =?us-ascii?Q?hVMMJX61JXfNDWnReVjT31i/QBOvc8MukDBCBkGIuVTrb69G/avVAwwXdM9f?=
 =?us-ascii?Q?aSfMsh0fmGUapOeNqb/gaVTeGnUNSW0IcG5shFjJ6qOWrc5OVnP758KZAP+4?=
 =?us-ascii?Q?txr+F1TcNJ9vr8GmLMvIbXeM1kOQ/oiaeok4+iL5vtJldwe7CSS+LnZUgXaz?=
 =?us-ascii?Q?V6dUkBupgmUkLmiYWN7O1jnp21F1Pt6lhsaywPG0TmUDDRW8N7Bx1YfgxQVE?=
 =?us-ascii?Q?s7SEq2qHCBPrBRxA52R8epqRvAqLBfdXvJ5P0VPrQs0/Sp8x+ycO2tkfwjvv?=
 =?us-ascii?Q?m9cwzo+FRmgfw8VbZZrAOVplxaHZnNQERzbDZiG92KFopF0VnzhM9oewI84c?=
 =?us-ascii?Q?HnpQZBejquRbiI25HSDzUAG3CjQ9zX9xJ0lrHO5lbGLPojnnaZCRi4AdzhD8?=
 =?us-ascii?Q?71ejmQ8z9adhrJCqdyMYPEK9arofkQOIFPnVAdmz8b7poSXMtVG6PDdOfMhp?=
 =?us-ascii?Q?EFt3hu9cAmgT7qWDJlArk4WhCOJSLVc2W1WgDMm9l7uh9Yym/3vfkVoUkA3q?=
 =?us-ascii?Q?k0X4REK8T0XMIegr4ODYj2Bawu/GIzQvNwrwovXcdivqVI6BGjcSCLjvON4x?=
 =?us-ascii?Q?v/nAoPp3hyE5ik2m1qg/LzvEz4DGkQBqQ21tTGUs?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5276.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d965f157-2a93-4cc2-1e3f-08dbbfecc865
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2023 06:33:09.7904
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3B5K3b6ln6k3vxZasKlq9/48CHY7Ugay3VRseuChlQrDlNVcFZ60xqr/N0zBCJ6eyCi2XjuhV2PZdykL/uaD1w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB6182
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Wed, 27 Sep 2023 23:34:00 -0700 (PDT)

> From: ankita@nvidia.com <ankita@nvidia.com>
> Sent: Friday, September 15, 2023 10:54 AM
>=20
> PCI BAR are aligned to the power-of-2, but the actual memory on the
> device may not. A read or write access to the physical address from the
> last device PFN up to the next power-of-2 aligned physical address
> results in reading ~0 and dropped writes.

Though the variant driver emulates the access to the offset beyond
the available memory size, how does the userspace driver or the guest
learn to know the actual size and avoid using the invalid hole to hold
valid data?

> +config NVGRACE_GPU_VFIO_PCI
> +	tristate "VFIO support for the GPU in the NVIDIA Grace Hopper
> Superchip"
> +	depends on ARM64 || (COMPILE_TEST && 64BIT)
> +	select VFIO_PCI_CORE
> +	help
> +	  VFIO support for the GPU in the NVIDIA Grace Hopper Superchip is
> +	  required to assign the GPU device to a VM using KVM/qemu/etc.

VFIO driver is not only for VM.

> +
> +static int nvgrace_gpu_vfio_pci_mmap(struct vfio_device *core_vdev,
> +				      struct vm_area_struct *vma)
> +{
> +	struct nvgrace_gpu_vfio_pci_core_device *nvdev =3D container_of(
> +		core_vdev, struct nvgrace_gpu_vfio_pci_core_device,
> core_device.vdev);
> +
> +	unsigned long start_pfn;
> +	unsigned int index;
> +	u64 req_len, pgoff, end;
> +	int ret =3D 0;
> +
> +	index =3D vma->vm_pgoff >> (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT);
> +	if (index !=3D VFIO_PCI_BAR2_REGION_INDEX)
> +		return vfio_pci_core_mmap(core_vdev, vma);
> +
> +	/*
> +	 * Request to mmap the BAR. Map to the CPU accessible memory on
> the
> +	 * GPU using the memory information gathered from the system ACPI
> +	 * tables.
> +	 */
> +	pgoff =3D vma->vm_pgoff &
> +		((1U << (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT)) - 1);
> +
> +	if (check_sub_overflow(vma->vm_end, vma->vm_start, &req_len) ||
> +		check_add_overflow(PHYS_PFN(nvdev->memphys), pgoff,
> &start_pfn) ||
> +		check_add_overflow(PFN_PHYS(pgoff), req_len, &end))
> +		return -EOVERFLOW;
> +
> +	/*
> +	 * Check that the mapping request does not go beyond available
> device
> +	 * memory size
> +	 */
> +	if (end > nvdev->memlength)
> +		return -EINVAL;
> +
> +	/*
> +	 * Perform a PFN map to the memory and back the device BAR by the
> +	 * GPU memory.
> +	 *
> +	 * The available GPU memory size may not be power-of-2 aligned.
> Given
> +	 * that the memory is exposed as a BAR, the mapping request is of
> the
> +	 * power-of-2 aligned size. Map only up to the size of the GPU

why is the mapping request in power-of-2? The caller should follow the
sparse mapping to raise the request. Otherwise the check on 'end' right
above will always fail.

> +
> +/*
> + * Read count bytes from the device memory at an offset. The actual devi=
ce
> + * memory size (available) may not be a power-of-2. So the driver fakes
> + * the size to a power-of-2 (reported) when exposing to a user space dri=
ver.
> + *
> + * Read request beyond the actual device size is filled with ~0, while
> + * those beyond the actual reported size is skipped.
> + *
> + * A read from a negative or a reported+ offset, a negative count are

it's hard to understand 'reported+'. Please update it with a descriptive
word.

> + * considered error conditions and returned with an -EINVAL.
> + */
> +ssize_t nvgrace_gpu_read_mem(void __user *buf, size_t count, loff_t *ppo=
s,
> +			      struct nvgrace_gpu_vfio_pci_core_device *nvdev)
> +{
> +	u64 offset =3D *ppos & VFIO_PCI_OFFSET_MASK;
> +	size_t mem_count, i, bar_size =3D roundup_pow_of_two(nvdev-
> >memlength);
> +	u8 val =3D 0xFF;
> +
> +	if (offset >=3D bar_size)
> +		return -EINVAL;
> +
> +	/* Clip short the read request beyond reported BAR size */
> +	count =3D min(count, bar_size - (size_t)offset);
> +
> +	/*
> +	 * Determine how many bytes to be actually read from the device
> memory.
> +	 * Do not read from the offset beyond available size.
> +	 */
> +	if (offset >=3D nvdev->memlength)
> +		return 0;

This violates the comment:

* Read request beyond the actual device size is filled with ~0, while
* those beyond the actual reported size is skipped.

> +
> +	mem_count =3D min(count, nvdev->memlength - (size_t)offset);
> +
> +	/*
> +	 * Handle read on the BAR2 region. Map to the target device memory
> +	 * physical address and copy to the request read buffer.
> +	 */
> +	if (copy_to_user(buf, (u8 *)nvdev->memmap + offset, mem_count))
> +		return -EFAULT;
> +
> +	/*
> +	 * Only the device memory present on the hardware is mapped,
> which may
> +	 * not be power-of-2 aligned. A read to the BAR2 region implies an
> +	 * access outside the available device memory on the hardware. Fill

Why is a read to BAR2 region implies an out-of-scope access?=20

> +static ssize_t nvgrace_gpu_vfio_pci_read(struct vfio_device *core_vdev,
> +					  char __user *buf, size_t count, loff_t
> *ppos)
> +{
> +	unsigned int index =3D VFIO_PCI_OFFSET_TO_INDEX(*ppos);
> +	struct nvgrace_gpu_vfio_pci_core_device *nvdev =3D container_of(
> +		core_vdev, struct nvgrace_gpu_vfio_pci_core_device,
> core_device.vdev);
> +
> +	if (index =3D=3D VFIO_PCI_BAR2_REGION_INDEX) {
> +		mutex_lock(&nvdev->memmap_lock);
> +		if (!nvdev->memmap) {
> +			nvdev->memmap =3D memremap(nvdev->memphys,
> nvdev->memlength, MEMREMAP_WB);
> +			if (!nvdev->memmap) {
> +				mutex_unlock(&nvdev->memmap_lock);
> +				return -ENOMEM;
> +			}
> +		}
> +		mutex_unlock(&nvdev->memmap_lock);

move above to a helper and share with the write fn.

> +ssize_t nvgrace_gpu_write_mem(size_t count, loff_t *ppos, const void
> __user *buf,
> +			       struct nvgrace_gpu_vfio_pci_core_device *nvdev)
> +{
> +	u64 offset =3D *ppos & VFIO_PCI_OFFSET_MASK;
> +	size_t mem_count, bar_size =3D roundup_pow_of_two(nvdev-
> >memlength);
> +
> +	if (offset >=3D bar_size)
> +		return -EINVAL;
> +
> +	/* Clip short the read request beyond reported BAR size */
> +	count =3D min(count, bar_size - (size_t)offset);

s/read/write/

> +
> +	/*
> +	 * Determine how many bytes to be actually written to the device
> memory.
> +	 * Do not write to the offset beyond available size.
> +	 */
> +	if (offset >=3D nvdev->memlength)
> +		return 0;

still need return count as no-write is still a success emulation of write.

ditto for the read fn.

> +
> +	mem_count =3D min(count, nvdev->memlength - (size_t)offset);
> +
> +	/*
> +	 * Only the device memory present on the hardware is mapped,
> which may
> +	 * not be power-of-2 aligned. A write to the BAR2 region implies an
> +	 * access outside the available device memory on the hardware. Drop
> +	 * those write requests.
> +	 */
> +	if (copy_from_user((u8 *)nvdev->memmap + offset, buf,
> mem_count))
> +		return -EFAULT;
> +
> +	return count;

*ppos is not adjusted. ditto for the read fn.

> +
> +static ssize_t coherent_mem_show(struct device *dev,
> +			    struct device_attribute *attr, char *buf)
> +{
> +	struct vfio_pci_core_device *core_device =3D dev_get_drvdata(dev);
> +	struct nvgrace_gpu_vfio_pci_core_device *nvdev
> +		=3D container_of(core_device, struct
> nvgrace_gpu_vfio_pci_core_device,
> +			       core_device);
> +
> +	return sprintf(buf, "%u\n", nvdev->memlength ? 1 : 0);

if nvdev->memlength is 0 then probe will fail.

So here can always return 1.