linux-kernel - RE: [PATCH v11 1/1] vfio/nvgpu: Add vfio pci variant module for grace hopper

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]

Date:   Wed, 11 Oct 2023 02:00:30 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>
CC:     "ankita@...dia.com" <ankita@...dia.com>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "yishaih@...dia.com" <yishaih@...dia.com>,
        "shameerali.kolothum.thodi@...wei.com" 
        <shameerali.kolothum.thodi@...wei.com>,
        "aniketa@...dia.com" <aniketa@...dia.com>,
        "cjia@...dia.com" <cjia@...dia.com>,
        "kwankhede@...dia.com" <kwankhede@...dia.com>,
        "targupta@...dia.com" <targupta@...dia.com>,
        "vsethi@...dia.com" <vsethi@...dia.com>,
        "Currid, Andy" <acurrid@...dia.com>,
        "apopple@...dia.com" <apopple@...dia.com>,
        "jhubbard@...dia.com" <jhubbard@...dia.com>,
        "danw@...dia.com" <danw@...dia.com>,
        "anuaggarwal@...dia.com" <anuaggarwal@...dia.com>,
        "dnigam@...dia.com" <dnigam@...dia.com>,
        "udhoke@...dia.com" <udhoke@...dia.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v11 1/1] vfio/nvgpu: Add vfio pci variant module for grace
 hopper

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Tuesday, October 10, 2023 7:34 PM
> 
> On Tue, Oct 10, 2023 at 08:42:13AM +0000, Tian, Kevin wrote:
> > > From: ankita@...dia.com <ankita@...dia.com>
> > > Sent: Sunday, October 8, 2023 4:23 AM
> > >
> > > PCI BAR are aligned to the power-of-2, but the actual memory on the
> > > device may not. A read or write access to the physical address from the
> > > last device PFN up to the next power-of-2 aligned physical address
> > > results in reading ~0 and dropped writes.
> > >
> >
> > my question to v10 was not answered. posted again:
> > --
> > Though the variant driver emulates the access to the offset beyond
> > the available memory size, how does the userspace driver or the guest
> > learn to know the actual size and avoid using the invalid hole to hold
> > valid data?
> 
> The device FW knows and tells the VM.
> 

This driver reads the size info from ACPI and records it as nvdev->memlength.

But nvdev->memlength is not exposed to the userspace. How does the virtual
FW acquires this knowledge and then report it to the VM?

One option is to indirectly decide the size based on sparse mmap info. But
that is kind of a misuse of sparse mmap then such misuse better fits to be
a device specific region as Alex suggested.

Did I overlook an important fact in the overall picture?