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]

Message-ID: <BN9PR11MB5276E36C876042AADD707AD08CF2A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Mon, 11 Sep 2023 07:12:21 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>,
        Christoph Hellwig <hch@...radead.org>
CC:     Alex Williamson <alex.williamson@...hat.com>,
        "ankita@...dia.com" <ankita@...dia.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>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v8 1/1] vfio/nvgpu: Add vfio pci variant module for grace
 hopper

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Friday, September 8, 2023 8:16 PM
> 
> On Fri, Sep 08, 2023 at 01:50:36AM -0700, Christoph Hellwig wrote:
> > On Thu, Sep 07, 2023 at 10:04:10PM -0600, Alex Williamson wrote:
> > > > 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.
> 
> Yes, I do prefer this because it is ultimately simpler on the qemu and
> VM side. This ACPI tinkering is not nice.
> 
> > > 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,
> 
> > Yes, providing something to a VM that doesn't look anything like the
> > underlying hardware feels pretty strange.
> 
> I don't see the goal as perfect emulation of the real HW.
> 
> Aiming for minimally disruptive to the ecosystem to support this
> quirky pre-CXL HW.
> 
> Perfect emulation would need a unique VFIO uAPI and more complex qemu
> changes, and it really brings nothing of value.
> 

Does it mean that this requires maintaining a new guest driver
different from the existing one on bare metal?