On Tue, Apr 23, 2019 at 05:26:53PM -0700, Sean Christopherson wrote: > On Tue, Apr 23, 2019 at 11:29:24PM +0000, Jethro Beekman wrote: > > On 2019-04-22 14:58, Sean Christopherson wrote: > > >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. > > This gets far outside of my area of expertise as I think this is more of > a policy question as opposed to a technical question, e.g. do we export > function simply to allow out-of-tree alternatives. > > > >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? > > Nope, userspace "only" needs to be able to mmap() arbitrary chunks of EPC. > Except for EPC management, which is already in built into the kernel, the > EPC virtualization code has effectively zero overlap with the driver. Of > course this is all technically speculative since none of this is upstream... Jarkko, can you weigh in with your thoughts on the ACPI stuff?
