linux-kernel - Re: [PATCH v8 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:   Thu, 7 Sep 2023 22:04:10 -0600
From:   Alex Williamson <alex.williamson@...hat.com>
To:     Jason Gunthorpe <jgg@...dia.com>
Cc:     ankita@...dia.com, yishaih@...dia.com,
        shameerali.kolothum.thodi@...wei.com, kevin.tian@...el.com,
        aniketa@...dia.com, cjia@...dia.com, kwankhede@...dia.com,
        targupta@...dia.com, vsethi@...dia.com, acurrid@...dia.com,
        apopple@...dia.com, jhubbard@...dia.com, danw@...dia.com,
        anuaggarwal@...dia.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH v8 1/1] vfio/nvgpu: Add vfio pci variant module for
 grace hopper

On Thu, 7 Sep 2023 21:34:41 -0300
Jason Gunthorpe <jgg@...dia.com> wrote:

> On Thu, Sep 07, 2023 at 01:55:46PM -0600, Alex Williamson wrote:
> 
> > There's perhaps an argument whether userspace should compose this
> > device itself, for example finding the firmware attributes in sysfs and
> > directly mmap'ing the coherent memory via /dev/mem to back a virtual
> > BAR or otherwise pass-through this associated region.    
> 
> I don't think this works, secure boot turns off /dev/mem and other
> things that would let you do this AFAIK.

Yep, it's got issues, just trying to play devil's advocate for a
non-kernel approach.

> > I've previously raised the point whether the coherent region here
> > might be exposed as a device specific region (such as we do for the
> > above IGD regions) rather than a virtual BAR, but the NVIDIA folks feel
> > strongly that the BAR approach is correct.  
> 
> I think it really depends on what the qemu side wants to do..

Ok, I thought you had been one of the proponents of the fake BAR
approach as more resembling CXL.  Do we need to reevaluate that the
tinkering with the VM machine topology and firmware tables would better
align to a device specific region that QEMU inserts into the VM address
space so that bare metal and virtual machine versions of this device
look more similar?  Thanks,

Alex