linux-kernel - Re: [PATCH v1 1/1] vfio/nvgpu: Add vfio pci variant module for grace hopper device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZEfPsm+SVRC/P5T2@ziepe.ca>
Date:   Tue, 25 Apr 2023 10:03:46 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     ankita@...dia.com, aniketa@...dia.com, cjia@...dia.com,
        kwankhede@...dia.com, targupta@...dia.com, vsethi@...dia.com,
        acurrid@...dia.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/1] vfio/nvgpu: Add vfio pci variant module for grace
 hopper device

On Thu, Apr 20, 2023 at 05:17:20PM -0600, Alex Williamson wrote:

> > +	/*
> > +	 * Perform a PFN map to the memory. The device BAR1 is backed by the
> > +	 * GPU memory now. Check that the mapping does not overflow out of
> > +	 * the GPU memory size.
> > +	 */
> > +	ret = remap_pfn_range(vma, vma->vm_start, start_pfn + pgoff,
> > +			      min(req_len, nvdev->mem_prop.mem_length - pgoff),
> > +			      vma->vm_page_prot);
> 
> What's the behavior of this "BAR" relative to things like
> PCI_COMMAND_MEMORY or reset?  If the user generates a secondary bus
> reset on the parent bridge in one thread, while accessing the device in
> another thread, isn't that susceptible to platform error handling just
> like any other PCI device?  

This space works more like RAM and it is made cachable as well which
changes how errors are managed compared to PCI.

It doesn't generate any unhandled failures, so we don't need the zap
protection here.

Jason