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

From: Jason Gunthorpe
Date: Tue May 16 2023 - 20:28:49 EST


On Tue, May 16, 2023 at 03:09:14PM -0600, Alex Williamson wrote:

> > +# SPDX-License-Identifier: GPL-2.0-only
> > +config NVGPU_VFIO_PCI
> > + tristate "VFIO support for the GPU in the NVIDIA Grace Hopper Superchip"
> > + depends on ARM64 || (COMPILE_TEST && 64BIT)
> > + select VFIO_PCI_CORE
>
> I think this should be a 'depends on' as well, that's what we have for
> the other vfio-pci variant drivers.

It should be removed completely, AFAICT:

config VFIO_PCI
tristate "Generic VFIO support for any PCI device"
select VFIO_PCI_CORE

Ensures it is turned on

if VFIO_PCI
source "drivers/vfio/pci/mlx5/Kconfig"
endif

Autoamtically injects a 'depends on VFIO_PCI' to all the enclosed
kconfig statements (and puts them nicely in the menu)

So we have everything needed already

SELECT is the correct action since it doesn't have a config text.

> Is our test for vm_end < vm_start in vfio-pci-core just paranoia? I
> don't see an equivalent here.

Yes, mm core will not invoke the op with something incorrect.

> Can we also get a comment in the code outlining the various reasons
> that this "BAR" doesn't need the disabled access protections that
> vfio-pci-core implements? For example outlining the behavior relative
> to BAR access while the memory enable bit is disabled, the bus being in
> reset, or the device being in a low-power state.

The HW has some "isolation" feature that kicks in and safely
disconnects the GPU from the CPU.

A lot of work has been done to make things like VFIO and KVM safe
against machine checks/etc under basically all circumstances.

Jason