On Fri, Aug 02, 2019 at 10:33:38PM +0300, Jarkko Sakkinen wrote:
> On Thu, Aug 01, 2019 at 09:29:31AM -0700, Sean Christopherson wrote:
> > On Thu, Aug 01, 2019 at 07:22:19PM +0300, Jarkko Sakkinen wrote:
> > > On Mon, Jul 15, 2019 at 06:59:03AM -0700, Sean Christopherson wrote:
> > > > On Sun, Jul 14, 2019 at 05:32:12PM +0300, Jarkko Sakkinen wrote:
> > > > > When the config option is not enabled the initialization is always
> > > > > succesful.
> > > >
> > > > Why would the be initialization be considered successful? It's dead code
> > > > and memory consumption if the driver can't load. When KVM support gets
> > > > added, the initialization can be considered successful if the driver *or*
> > > > virtual EPC are enabled and load cleanly.
> > >
> > > When a config option disabled means it that the functionality does not
> > > exist at all, which means that there is nothing to fail. That is why it
> > > would be actually better to flag the whole call than the way it is done
> > > in this patch.
> >
> > Regardless of how it's done, the core SGX management shouldn't consume
> > resources if it doesn't have downstream consumers. Making INTEL_SGX
> > depend on INTEL_SGX_DRIVER is the obvious alternative.
>
> Is there a specific blocker that prevents using SGX just with KVM when
> the latter option is disabled?
Nope, KVM does not have any dependencies on the native driver. But if
sgx_drv_init() returns 0 when CONFIG_INTEL_SGX_DRIVER=n, then sgx_init()
won't handle KVM failure correctly since it will think the native driver
initialized cleanly. E.g. with both KVM and driver in play, I was
thinking of something like this in sgx_init():
/* Success if the native *or* virtual driver initialized cleanly. */
ret = sgx_drv_init();
ret = sgx_virt_epc_init() ? ret : 0;
if (ret)
goto err;
return 0;
If sgx_drv_init() returns 0 when CONFIG_INTEL_SGX_DRIVER=n, then failure
in sgx_virt_epc_init() is ignored and we end up with the SGX subsystem
wasting resources again.
