linux-kernel - Re: [PATCH v15 1/1] vfio/nvgrace-gpu: 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] [day] [month] [year] [list]

Message-ID:
 <SA1PR12MB719969304142495D09BF7204B06A2@SA1PR12MB7199.namprd12.prod.outlook.com>
Date: Tue, 9 Jan 2024 11:42:37 +0000
From: Ankit Agrawal <ankita@...dia.com>
To: Jason Gunthorpe <jgg@...dia.com>, Alex Williamson
	<alex.williamson@...hat.com>
CC: Yishai Hadas <yishaih@...dia.com>, "shameerali.kolothum.thodi@...wei.com"
	<shameerali.kolothum.thodi@...wei.com>, "kevin.tian@...el.com"
	<kevin.tian@...el.com>, "eric.auger@...hat.com" <eric.auger@...hat.com>,
	"brett.creeley@....com" <brett.creeley@....com>, "horms@...nel.org"
	<horms@...nel.org>, Aniket Agashe <aniketa@...dia.com>, Neo Jia
	<cjia@...dia.com>, Kirti Wankhede <kwankhede@...dia.com>, "Tarun Gupta
 (SW-GPU)" <targupta@...dia.com>, Vikram Sethi <vsethi@...dia.com>, Andy
 Currid <acurrid@...dia.com>, Alistair Popple <apopple@...dia.com>, John
 Hubbard <jhubbard@...dia.com>, Dan Williams <danw@...dia.com>, "Anuj Aggarwal
 (SW-GPU)" <anuaggarwal@...dia.com>, Matt Ochs <mochs@...dia.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v15 1/1] vfio/nvgrace-gpu: Add vfio pci variant module for
 grace hopper

I am working to get the code changes suggested in this thread to get
to the next version.

Moreover based on the other design related comments for BAR approach
and support for the enable/disable bit, comments follow.

> There are a lot of VMMs and OSs this needs to support so it must all
> be consistent. For better or worse the decision was taken for the vPCI
> spec to use BAR not ACPI, in part due to feedback from the broader VMM
> ecosystem, and informed by future product plans.
> 
> So, if vfio does special regions then qemu and everyone else has to
> fix it to meet the spec.

Ack, I'm putting this into the commit log as a reason to go with the BAR
approach for future reference.

>>> I'd suggest we take a look at whether we need to continue to pursue
>>> honoring the memory enable bit for these BARs and make a conscious and
>>> documented decision if we choose to ignore it.
>>
>> Let's document it.
> Ok, I'd certainly appreciate more background around why it was chosen
> to expose the device differently than bare metal in the commit log and
> code comments and in particular why we're consciously choosing not to
> honor these specific PCI semantics.  Presumably we'd remove the -EIO
> from the r/w path based on the memory enable state as well.

Ack, will add to the commit log and remove EIO.

>> unprogrammed BARs are ignored (ie. not exposed to userspace), so perhaps
>> as long as it can be guaranteed that an access with the address space
>> enable bit cleared cannot generate a system level fault, we actually
>> have no strong argument to strictly enforce the address space bits.
>
> This is what I think, yes.

Ack, so given the access does not cause system level fault, I'll not enforce
the enable/disable bit. Though I'll put this information in the commit log
for reference as well and the reason for this choice.