[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9374e410-4357-840d-7b1d-40bd27cd78a6@amd.com>
Date: Mon, 2 Oct 2017 11:35:47 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Borislav Petkov <bp@...e.de>
Cc: Brijesh Singh <brijesh.singh@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
kvm@...r.kernel.org, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option
On 10/2/2017 8:51 AM, Borislav Petkov wrote:
> On Mon, Oct 02, 2017 at 08:44:21AM -0500, Tom Lendacky wrote:
>> I think we're talking about the same thing. You want sev_enabled to
>> indicate whether you can launch an SEV guest. We would still need an
>> sev_active variable to distinguish between SME and SEV during kernel
>> execution when the sme_me_mask is non-zero. Currently, the SEV feature
>> bit acts as "sev_enabled" and the sev_enabled variable acts as
>> "sev_active" in this scenario.
>
> See my last email about sev_host_enabled. Does that sound better?
Hmmm... strange, I haven't received that email or that part of the thread
for that matter - including Brijesh's reply. I'll talk with Brijesh and
let him run with it.
Thanks,
Tom
>
Powered by blists - more mailing lists