Re: [RFC PATCH v3 08/27] x86/sgx: Initialize virtual EPC driver even when SGX driver is disabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 04, 2021 at 05:05:56AM +0200, Jarkko Sakkinen wrote:
> On Thu, Feb 04, 2021 at 03:59:20PM +1300, Kai Huang wrote:
> > On Thu, 2021-02-04 at 03:39 +0200, Jarkko Sakkinen wrote:
> > > On Wed, Feb 03, 2021 at 02:59:47PM -0800, Sean Christopherson wrote:
> > > > On Thu, Feb 04, 2021, Jarkko Sakkinen wrote:
> > > > > On Wed, Feb 03, 2021 at 01:49:06PM +1300, Kai Huang wrote:
> > > > > > What working *incorrectly* thing is related to SGX virtualization? The things
> > > > > > SGX virtualization requires (basically just raw EPC allocation) are all in
> > > > > > sgx/main.c. 
> > > > > 
> > > > > States:
> > > > > 
> > > > > A. SGX driver is unsupported.
> > > > > B. SGX driver is supported and initialized correctly.
> > > > > C. SGX driver is supported and failed to initialize.
> > > > > 
> > > > > I just thought that KVM should support SGX when we are either in states A
> > > > > or B.  Even the short summary implies this. It is expected that SGX driver
> > > > > initializes correctly if it is supported in the first place. If it doesn't,
> > > > > something is probaly seriously wrong. That is something we don't expect in
> > > > > a legit system behavior.
> > > > 
> > > > It's legit behavior, and something we (you?) explicitly want to support.  See
> > > > patch 05, x86/cpu/intel: Allow SGX virtualization without Launch Control support.
> > > 
> > > What I think would be a sane behavior, would be to allow KVM when
> > > sgx_drv_init() returns -ENODEV (case A). This happens when LC is
> > > not enabled:
> > > 
> > > 	if (!cpu_feature_enabled(X86_FEATURE_SGX_LC))
> > > 		return -ENODEV;
> > > 
> > > /Jarkko
> > 
> > I really don't understand what's the difference between A and C. When "SGX driver is
> > supported and failed to initialize" happens, it just means "SGX driver is
> > unsupported". If it is not the case, can you explicitly point out what will be the
> > problem?

This is as explicit as I can ever possibly get:

A: ret == -ENODEV
B: ret == 0
C: ret != 0 && ret != -ENODEV

/Jarkko



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux