Re: [Xen-devel] [PATCH 02/15] xen: vmx: detect ENCLS VMEXIT

["Huang, Kai" <kai.huang@xxxxxxxxxxxxxxx>]

On 7/13/2017 6:54 AM, Jan Beulich wrote:
> > > > Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 07/12/17 1:12 PM >>>
> > On 09/07/17 10:09, Kai Huang wrote:
> > > If ENCLS VMEXIT is not present then we cannot support SGX virtualization.
> > > This patch detects presence of ENCLS VMEXIT. A Xen boot boolean parameter
> > > 'sgx' is also added to manually enable/disable SGX.
> > >
> > > Signed-off-by: Kai Huang <kai.huang@xxxxxxxxxxxxxxx>
> > At a minimum, you also need to modify calculate_hvm_max_policy() to hide
> > SGX if we don't have ENCLS intercept support.
Actually IMO this is not needed, as I added an __initcall(sgx_init) (see 
patch 0003), where I will call setup_clear_cpu_cap(X86_FEATURE_SGX) if 
for any reason boot_sgx_cpuidata (which contains common SGX cpuid info 
shared by all cores) doesn't have valid SGX info. if ENCLS VMEXIT is not 
present, then detect_sgx won't be called for any core so that 
X86_FEATURE_SGX will be cleared in boot_cpu_data. As init_guest_cpuid is 
called after all __initcalls are called, so if ENCLS VMEXIT is not 
present, or sgx is disabled via boot parameter, then even for 
host_policy, it won't have SGX.
Of course if we changed the implementation of __initcall(sgx_init), we 
probably need to explicitly clear SGX here. Anyway clearing SGX here 
doesn't have any harm, so I am completely fine to do it if you think it 
is necessary.
> Additionally I think the command line option should default to off initially
> and it needs an entry in the command line option doc.
Sure. I'll change default to 0 and change the doc as well.

Thanks,
-Kai
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel