Message-ID: <31ead5ce-fb38-4c0d-9bf9-606b59d6da09@linux.microsoft.com>
Date: Tue, 11 Jun 2024 19:25:27 +0200
From: Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>
To: Chris Oo <cho@...rosoft.com>, Dave Hansen <dave.hansen@...el.com>,
 "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>,
 "H. Peter Anvin" <hpa@...or.com>
Cc: "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Dexuan Cui <decui@...rosoft.com>, John Starks <John.Starks@...rosoft.com>
Subject: Re: [EXTERNAL] Re: [PATCH] x86/tdx: Generate SIGBUS on userspace MMIO

On 11/06/2024 19:17, Chris Oo wrote:
> We have a usecase where we have device drivers in usermode using vfio that mmap regions of the address space to access device BARs. In this case, when the #VE handler cannot emulate mmio on behalf of usermode, we need the SIGBUS to know if we should retry the attempt via doing a write via the vfio file descriptor. 
> 
> We don't want to have every mmio go through the vfio file descriptor, because for pages that are actually backed by physical device's BAR we won't take a #VE and introduce a bunch of extra path length, but only if the host has chosen to emulate some page in that BAR. We also don't have any way of knowing which pages will cause a #VE because there's no way for the guest to query which pages the host has chosen to emulate accesses on. 
> 
> Chris
> 
> -----Original Message-----
> From: Dave Hansen <dave.hansen@...el.com> 
> Sent: Tuesday, June 11, 2024 9:16 AM
> To: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>; Dave Hansen <dave.hansen@...ux.intel.com>; Thomas Gleixner <tglx@...utronix.de>; Ingo Molnar <mingo@...hat.com>; Borislav Petkov <bp@...en8.de>; x86@...nel.org; H. Peter Anvin <hpa@...or.com>
> Cc: linux-coco@...ts.linux.dev; linux-kernel@...r.kernel.org; Chris Oo <cho@...rosoft.com>; Dexuan Cui <decui@...rosoft.com>; John Starks <John.Starks@...rosoft.com>
> Subject: [EXTERNAL] Re: [PATCH] x86/tdx: Generate SIGBUS on userspace MMIO
> 
> [Some people who received this message don't often get email from dave.hansen@...el.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On 6/10/24 06:55, Dave Hansen wrote:
>>> Enlightened userspace may choose to handle MMIO on their own if the 
>>> kernel does not emulate it.
>>>
>>> Handle the EPT_VIOLATION exit reason for userspace and deliver SIGBUS 
>>> instead of SIGSEGV. SIGBUS is more appropriate for the MMIO situation.
>> Is any userspace _actually_ doing this?  Sure, SIGBUS is more 
>> appropriate but in practice unprepared userspace crashes either way.
> 
> I also can't help but wonder if there's a better way to do this.
> 
> Just thinking out loud.... Ideally, we'd reject creating a potentially troublesome VMA at mmap() time.  That's way better than, for instance, panic()'ing at some random place in the middle of program execution.
> 
> But I guess that's likely not possible because someone could be doing a VM_MIXEDMAP VMA that only has normal private pages and never _actually_ needs or has a shared page mapped.
> 
> I'd still love to know what actual kernel drivers and actual userspace would be involved in this whole dance.  It's still way too theoretical for me.

Is there a reason we can't fix the handler to do the #VE->mmio emulation for userspace too, so that this scenario
works just like outside of a CVM?

Powered by blists - more mailing lists