On Thu, 2021-02-04 at 05:09 +0200, Jarkko Sakkinen wrote: > 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 Let me try again: Why A and C should be treated differently? What will behave incorrectly, in case of C? > > /Jarkko
