[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c07e1f1e-f93d-dbc6-f7bb-11c7488f4e2f@linux.intel.com>
Date: Tue, 18 May 2021 09:10:04 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Dave Hansen <dave.hansen@...el.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>
Cc: Tony Luck <tony.luck@...el.com>,
Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Raj Ashok <ashok.raj@...el.com>,
Sean Christopherson <seanjc@...gle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC v2-fix 1/1] x86/tdx: Handle in-kernel MMIO
>>>> For now we only handle a subset of instructions that the kernel
>>>> uses for MMIO operations. User-space access triggers SIGBUS.
>>> How do you know which instructions the kernel uses?
>> They're all in MMIO macros.
> I've heard exactly the opposite from the TDX team in the past. What I
> remember was a claim that one can not just leverage the MMIO macros as a
> single point to avoid MMIO. I remember being told that not all code in
> the kernel that does MMIO uses these macros. APIC MMIO's were called
> out as a place that does not use the MMIO macros.
Yes x86 APIC has its own macros, but we don't use the MMIO based APIC,
only X2APIC in TDX.
I'm not aware of any other places that would do MMIO without using the
standard io.h macros, although it might happen in theory on x86 (but
would likely break on some other architectures)
-Andi
Powered by blists - more mailing lists