Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}
From: Dan Williams <hidden>
Date: 2021-08-24 21:59:57
Also in:
linux-arch, linux-doc, linux-mips, linux-pci, lkml, sparclinux, virtualization
On Tue, Aug 24, 2021 at 2:57 PM Rajat Jain [off-list ref] wrote:
On Mon, Aug 23, 2021 at 6:06 PM Dan Williams [off-list ref] wrote:quoted
On Mon, Aug 23, 2021 at 5:31 PM Kuppuswamy, Sathyanarayanan [off-list ref] wrote:quoted
On 8/23/21 4:56 PM, Michael S. Tsirkin wrote:quoted
quoted
Add a new variant of pci_iomap for mapping all PCI resources of a devices as shared memory with a hypervisor in a confidential guest. Signed-off-by: Andi Kleen<redacted> Signed-off-by: Kuppuswamy Sathyanarayanan<sathyanarayanan.kuppuswamy@linux.intel.com>I'm a bit puzzled by this part. So why should the guest*not* map pci memory as shared? And if the answer is never (as it seems to be) then why not just make regular pci_iomap DTRT?It is in the context of confidential guest (where VMM is un-trusted). So we don't want to make all PCI resource as shared. It should be allowed only for hardened drivers/devices.That's confusing, isn't device authorization what keeps unaudited drivers from loading against untrusted devices? I'm feeling like Michael that this should be a detail that drivers need not care about explicitly, in which case it does not need to be exported because the detail can be buried in lower levels. Note, I specifically said "unaudited", not "hardened" because as Greg mentioned the kernel must trust drivers, its devices that may not be trusted.Can you please point me to the thread where this discussion with Greg is ongoing?
It slowed down to implement the "move to the 'authorized' device model" recommendation. LWN has a good writeup (as usual) and a link to the thread: https://lwn.net/Articles/865918/