[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47ccc32e-e113-48e0-d2e0-2f23b37cc452@amd.com>
Date: Tue, 25 Jul 2017 09:58:54 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Borislav Petkov <bp@...e.de>
Cc: Brijesh Singh <brijesh.singh@....com>,
linux-kernel@...r.kernel.org, x86@...nel.org,
linux-efi@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
kvm@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H . Peter Anvin" <hpa@...or.com>,
Andy Lutomirski <luto@...nel.org>,
Tony Luck <tony.luck@...el.com>,
Piotr Luc <piotr.luc@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Lu Baolu <baolu.lu@...ux.intel.com>,
Reza Arbab <arbab@...ux.vnet.ibm.com>,
David Howells <dhowells@...hat.com>,
Matt Fleming <matt@...eblueprint.co.uk>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Laura Abbott <labbott@...hat.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Eric Biederman <ebiederm@...ssion.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Jonathan Corbet <corbet@....net>,
Dave Airlie <airlied@...hat.com>,
Kees Cook <keescook@...omium.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Arnd Bergmann <arnd@...db.de>, Tejun Heo <tj@...nel.org>,
Christoph Lameter <cl@...ux.com>
Subject: Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted
Virtualization CPU feature
On 7/25/2017 9:36 AM, Borislav Petkov wrote:
> On Tue, Jul 25, 2017 at 09:29:40AM -0500, Tom Lendacky wrote:
>> Yup, we can do something like that. I believe the only change that
>> would be needed to your patch would be to move the IS_ENABLED() check
>> to after the physical address space reduction check.
>
> Yeah, I wasn't sure about that. The logic is that if BIOS has enabled
> SME and thus reduction is in place, we need to update x86_phys_bits on
> 32-bit regardless, right?
>
> But, come to think of it, that reduction won't have any effect since we
> have 32-bit addresses and the reduction is above 32-bits, right? And
> thus it is moot.
True, but it is more about being accurate and making sure the value is
correct where ever it may be used.
Thanks,
Tom
>
> Or?
>
Powered by blists - more mailing lists