lkml.org 
[lkml]   [2020]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2] KVM: SVM: Override default MMIO mask if memory encryption is enabled
From
Date
On 1/6/20 5:38 PM, Sean Christopherson wrote:
> On Mon, Jan 06, 2020 at 05:14:04PM -0600, Tom Lendacky wrote:
>> On 1/6/20 4:49 PM, Sean Christopherson wrote:
>>> This doesn't handle the case where x86_phys_bits _isn't_ reduced by SME/SEV
>>> on a future processor, i.e. x86_phys_bits==52.
>>
>> Not sure I follow. If MSR_K8_SYSCFG_MEM_ENCRYPT is set then there will
>> always be a reduction in physical addressing (so I'm told).
>
> Hmm, I'm going off APM Vol 2, which states, or at least strongly implies,
> that reducing the PA space is optional. Section 7.10.2 is especially
> clear on this:
>
> In implementations where the physical address size of the processor is
> reduced when memory encryption features are enabled, software must
> ensure it is executing from addresses where these upper physical address
> bits are 0 prior to setting SYSCFG[MemEncryptionModEn].

It's probably not likely, but given what is stated, I can modify my patch
to check for a x86_phys_bits == 52 and skip the call to set the mask, eg:

if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT &&
boot_cpu_data.x86_phys_bits < 52) {

>
> But, hopefully the other approach I have in mind actually works, as it's
> significantly less special-case code and would naturally handle either
> case, i.e. make this a moot point.

I'll hold off on the above and wait for your patch.

Thanks,
Tom

>
>
> Entry on SYSCFG:
>
> 3.2.1 System Configuration Register (SYSCFG)
>
> ...
>
> MemEncryptionMode. Bit 23. Setting this bit to 1 enables the SME and
> SEV memory encryption features.
>
> The SME entry the above links to says:
>
> 7.10.1 Determining Support for Secure Memory Encryption
>
> ...
>
> Additionally, in some implementations, the physical address size of the
> processor may be reduced when memory encryption features are enabled, for
> example from 48 to 43 bits. In this case the upper physical address bits are
> treated as reserved when the feature is enabled except where otherwise
> indicated. When memory encryption is supported in an implementation, CPUID
> Fn8000_001F[EBX] reports any physical address size reduction present. Bits
> reserved in this mode are treated the same as other page table reserved bits,
> and will generate a page fault if found to be non-zero when used for address
> translation.
>
> ...
>
> 7.10.2 Enabling Memory Encryption Extensions
>
> Prior to using SME, memory encryption features must be enabled by setting
> SYSCFG MSR bit 23 (MemEncryptionModEn) to 1. In implementations where the
> physical address size of the processor is reduced when memory encryption
> features are enabled, software must ensure it is executing from addresses where
> these upper physical address bits are 0 prior to setting
> SYSCFG[MemEncryptionModEn]. Memory encryption is then further controlled via
> the page tables.
>

\
 
 \ /
  Last update: 2020-01-07 21:17    [W:1.828 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site