On 2019-04-22 14:58, Sean Christopherson wrote: > +Cc Jethro > > On Wed, Apr 17, 2019 at 01:39:25PM +0300, Jarkko Sakkinen wrote: >> Intel Software Guard eXtensions (SGX) is a set of CPU instructions that >> can be used by applications to set aside private regions of code and >> data. The code outside the enclave is disallowed to access the memory >> inside the enclave by the CPU access control. >> >> This commit adds the Linux SGX Enclave Driver that provides an ioctl API >> to manage enclaves. The address range for an enclave, commonly referred >> as ELRANGE in the documentation (e.g. Intel SDM), is reserved with >> mmap() against /dev/sgx/enclave. After that a set ioctls is used to >> build the enclave to the ELRANGE. >> >> Signed-off-by: Jarkko Sakkinen >> Co-developed-by: Sean Christopherson >> Signed-off-by: Sean Christopherson >> Co-developed-by: Serge Ayoun >> Signed-off-by: Serge Ayoun >> Co-developed-by: Shay Katz-zamir >> Signed-off-by: Shay Katz-zamir >> Co-developed-by: Suresh Siddha >> Signed-off-by: Suresh Siddha >> --- > > ... > >> +#ifdef CONFIG_ACPI >> +static struct acpi_device_id sgx_device_ids[] = { >> + {"INT0E0C", 0}, >> + {"", 0}, >> +}; >> +MODULE_DEVICE_TABLE(acpi, sgx_device_ids); >> +#endif >> + >> +static struct platform_driver sgx_drv = { >> + .probe = sgx_drv_probe, >> + .remove = sgx_drv_remove, >> + .driver = { >> + .name = "sgx", >> + .acpi_match_table = ACPI_PTR(sgx_device_ids), >> + }, >> +}; > > Where do we stand on removing the ACPI and platform_driver dependencies? > Can we get rid of them sooner rather than later? You know my position on this... https://www.spinics.net/lists/linux-sgx/msg00624.html . I don't really have any new arguments. Considering the amount of planned changes for the driver post-merge, I think it's crucial that the driver part can be swapped out with alternative implementations. > Now that the core SGX code is approaching stability, I'd like to start > sending RFCs for the EPC virtualization and KVM bits to hash out that side > of things. The ACPI crud is the last chunk of code that would require > non-trivial changes to the core SGX code for the proposed virtualization > implementation. I'd strongly prefer to get it out of the way before > sending the KVM RFCs. What kind of changes? Wouldn't KVM just be another consumer of the same API used by the driver? -- Jethro Beekman | Fortanix