[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <040a760a-de34-f184-1157-0c8c2d5fcacd@linux.intel.com>
Date: Wed, 9 Jun 2021 07:56:14 -0700
From: "Kuppuswamy, Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...el.com>,
Tony Luck <tony.luck@...el.com>,
Andi Kleen <ak@...ux.intel.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,
Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [RFC v2-fix-v2 1/1] x86: Introduce generic protected guest
abstraction
On 6/9/21 7:32 AM, Borislav Petkov wrote:
> On Wed, Jun 09, 2021 at 07:01:13AM -0700, Kuppuswamy, Sathyanarayanan wrote:
>> I am still not clear. What happens when a driver which includes
>> linux/protected-guest.h is compiled for non-x86 arch (s390 or arm64)?
>
> I was wondering what felt weird: why is prot{ected,}_guest_has() in a
> generic linux/ namespace header and not in an asm/ one?
>
> I think the proper way is for the other arches should be to provide
> their own prot_guest_has() implementation which generic code uses and
> the generic header would contain only the PR_GUEST_* defines.
>
> Take ioremap() as an example:
>
> arch/x86/include/asm/io.h
> arch/arm64/include/asm/io.h
> arch/s390/include/asm/io.h
> ...
>
> and pretty much every arch has that arch-specific io.h header which
> defines ioremap() and generic code includes include/linux/io.h which
> includes the respective asm/io.h header so that users can call the
> respective ioremap() implementation.
>
> prot_guest_has() sounds just the same to me.
ioremap() is required for all architectures. So I think adding support for it
and creating io.h for every arch seems valid. But are you sure every arch cares
about protected guest support?
IMHO, its better to leave it to arch maintainers to decide if they want
to support protected guest or not.
This can be easily achieved by defining generic arch independent config
option ARCH_HAS_PORTECTED_GUEST.
And any arch which wants to support prot_guest_has() can enable above
config option and create their own asm/protected_guest.h
This model is similar to linux/mem_encrypt.h.
With above suggested change, header file will look like below. And we
don't need implement asm/protected_guest.h for every available arch.
--- a/include/linux/protected_guest.h
+++ b/include/linux/protected_guest.h
#ifndef _LINUX_PROTECTED_GUEST_H
#define _LINUX_PROTECTED_GUEST_H 1
/* Protected Guest Feature Flags (leave 0-0xff for arch specific flags) */
/* Support for guest encryption */
#define PR_GUEST_MEM_ENCRYPT 0x100
/* Encryption support is active */
#define PR_GUEST_MEM_ENCRYPT_ACTIVE 0x101
/* Support for unrolled string IO */
#define PR_GUEST_UNROLL_STRING_IO 0x102
/* Support for host memory encryption */
#define PR_GUEST_HOST_MEM_ENCRYPT 0x103
/* Support for shared mapping initialization (after early init) */
#define PR_GUEST_SHARED_MAPPING_INIT 0x104
#ifdef ARCH_HAS_PROTECTED_GUEST
#include <asm/protected_guest.h>
#else
static inline bool prot_guest_has(unsigned long flag) { return false; }
#endif
#endif /* _LINUX_PROTECTED_GUEST_H */
>
> Better?
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
Powered by blists - more mailing lists