On 6/8/2017 5:01 PM, Andrew Cooper wrote: > On 08/06/2017 22:17, Boris Ostrovsky wrote: >> On 06/08/2017 05:02 PM, Tom Lendacky wrote: >>> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: >>>>>> What may be needed is making sure X86_FEATURE_SME is not set for PV >>>>>> guests. >>>>> And that may be something that Xen will need to control through either >>>>> CPUID or MSR support for the PV guests. >>>> >>>> Only on newer versions of Xen. On earlier versions (2-3 years old) leaf >>>> 0x80000007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG. >>> The SME feature is in leaf 0x8000001f, is that leaf passed to the guest >>> unchanged? >> Oh, I misread the patch where X86_FEATURE_SME is defined. Then all >> versions, including the current one, pass it unchanged. >> >> All that's needed is setup_clear_cpu_cap(X86_FEATURE_SME) in >> xen_init_capabilities(). > > AMD processors still don't support CPUID Faulting (or at least, I > couldn't find any reference to it in the latest docs), so we cannot > actually hide SME from a guest which goes looking at native CPUID. > Furthermore, I'm not aware of any CPUID masking support covering that leaf. > > However, if Linux is using the paravirtual cpuid hook, things are > slightly better. > > On Xen 4.9 and later, no guests will see the feature. On earlier > versions of Xen (before I fixed the logic), plain domUs will not see the > feature, while dom0 will. > > For safely, I'd recommend unilaterally clobbering the feature as Boris > suggested. There is no way SME will be supportable on a per-PV guest That may be too late. Early boot support in head_64.S will make calls to check for the feature (through CPUID and MSR), set the sme_me_mask and encrypt the kernel in place. Is there another way to approach this? > basis, although (as far as I am aware) Xen as a whole would be able to > encompass itself and all of its PV guests inside one single SME instance. Yes, that is correct. Thanks, Tom > > ~Andrew >
