Re: [PATCH] vfio/nvgrace-gpu: Skip PFN registration for empty memory regions

[Andrea Parri <parri.andrea@gmail.com>]

On Fri, Oct 09, 2026 at 01:52:03PM -0600, Alex Williamson wrote:
> It seems to me though that the reason this bug exists is because
> nvgrace_gpu_pci_core_ops.open_device is trying to handle both real
> nvgrace devices, where usemem.memlength cannot be zero, alongside
> non-nvgrace devices where that can easily be forgotten.
>
> The above patches the failure of that model, but maybe the better
> approach is to split them such that the failures like this cannot
> occur, ie. a core-only wrapper that just calls vfio_pci_core_enable()
> and vfio_pci_core_finish_enable(), or some other refactor such that the
> core-only path never handles the nvdev.  Thanks,

Agreed, that's a better fix.  For v2 I have:

  1/2 gives nvgrace_gpu_pci_core_ops its own open_device, which only
      calls vfio_pci_core_enable() and vfio_pci_core_finish_enable(),
      to pair with vfio_pci_core_close_device().  The usemem.memlength
      guards from v1 are gone.

  2/2 drops the remaining usemem.memlength check in
      nvgrace_gpu_open_device(), since only devices with the ACPI
      memory properties reach it now.  Not for stable.

One visible change in fallback mode: open no longer fails when BAR0
cannot be mapped, the same as vfio-pci.  BAR0 was only mapped there for
the readiness check, which fallback mode never runs.  Ankit, please
shout if the fallback path relies on anything else from
nvgrace_gpu_open_device().

With 1/2 the reproducer from v1 (QEMU cxl-type3, fallback mode) no
longer hits the -EBUSY on reopen or the KASAN use-after-free after
unbind.

I'll wait a few days for Ankit's comments before posting v2.

Thanks,
  Andrea