Messages in this thread | | | Date | Fri, 28 Jul 2023 09:31:27 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH v5 1/1] vfio/nvgpu: Add vfio pci variant module for grace hopper |
| |
On Fri, Jul 28, 2023 at 04:36:05AM +0000, Ankit Agrawal wrote: > > >> +static ssize_t nvgrace_gpu_vfio_pci_read(struct vfio_device *core_vdev, > >> + char __user *buf, size_t count, loff_t *ppos) > >> +{ > >> + unsigned int index = VFIO_PCI_OFFSET_TO_INDEX(*ppos); > >> + struct nvgrace_gpu_vfio_pci_core_device *nvdev = container_of( > >> + core_vdev, struct nvgrace_gpu_vfio_pci_core_device, core_device.vdev); > >> + u64 offset = *ppos & VFIO_PCI_OFFSET_MASK; > >> + u8 val = 0xFF; > >> + size_t i; > >> + > >> + /* > >> + * Only the device memory present on the hardware is mapped, which may > >> + * not be power-of-2 aligned. A read to the BAR2 region implies an > >> + * access outside the available device memory on the hardware. > >> + */ > > > > This is not true, userspace has no requirement to only access BAR2 via > > mmap. This should support reads from within the coherent memory area. > > Just to confirm, the ask is to just update the comment to reflect the behavior, > right? (I missed to do that in this posting). Because we do redirect the call to > vfio_pci_core_read() here which will perform the read that is within the device > region. The read response to synthesize -1 is only for the range that is outside > the device memory region.
This doesn't seem right, vfio_pci_core_read() will use pci_iomap() to get a mapping which will be a DEVICE mapping, this will make the access incoherent with any cachable mappings.
Jason
| |