[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YJpP/S8MajKNhBl4@zn.tnic>
Date: Tue, 11 May 2021 11:35:57 +0200
From: Borislav Petkov <bp@...en8.de>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Dave Hansen <dave.hansen@...el.com>,
"Kuppuswamy, Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Andi Kleen <ak@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Tony Luck <tony.luck@...el.com>,
Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
Raj Ashok <ashok.raj@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC v2 28/32] x86/tdx: Make pages shared in ioremap()
On Mon, May 10, 2021 at 10:52:49PM +0000, Sean Christopherson wrote:
> I can't find the thread offhand, but Boris proposed something along the lines of
> cpu_has(), but specific to a given flavor of protected guest. IIRC, it was
> sev_guest_has(SEV_ES) or something like that.
>
> I 100% agree that we should have actual feature bits somewhere for the various
> protected guest flavors.
Preach brother! :)
/me goes and greps mailboxes...
ah, do you mean this, per chance:
https://lore.kernel.org/kvm/20210421144402.GB5004@zn.tnic/
?
And yes, this has "sev" in the name and dhansen makes sense to me in
wishing to unify all the protected guest feature queries under a common
name. And then depending on the vendor, that common name will call the
respective vendor's helper to answer the protected guest aspect asked
about.
This way, generic code will call
protected_guest_has()
or so and be nicely abstracted away from the underlying implementation.
Hohumm, yap, sounds nice to me.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists