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
