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
