On 5/18/2017 2:21 AM, Sean Christopherson wrote:
On Tue, 2017-05-16 at 11:56 +1200, Huang, Kai wrote:
On 5/16/2017 12:46 AM, Jarkko Sakkinen wrote:
On Thu, May 11, 2017 at 08:28:37PM -0700, Andy Lutomirski wrote:
[resending due to some kind of kernel.org glitch -- sorry if anyone
gets duplicates]
On Thu, May 11, 2017 at 5:32 PM, Huang, Kai <kai.huang@xxxxxxxxxxxxxxx>
wrote:
My current patch is based on this assumption. For KVM guest, naturally,
we
will write the cached value to real MSRs when vcpu is scheduled in. For
host, SGX driver should write its own value to MSRs when it performs
EINIT
for LE.
This seems unnecessarily slow (perhaps *extremely* slow) to me. I
would propose a totally different solution:
Have a percpu variable that stores the current SGXLEPUBKEYHASH along
with whatever lock is needed (probably just a mutex). Users of EINIT
will take the mutex, compare the percpu variable to the desired value,
and, if it's different, do WRMSR and update the percpu variable.
This is exactly what I've been suggesting internally: trap EINIT and
check the value and write conditionally.
I think this would be the best starting point.
OK. Assuming we are going to have this percpu variable for
IA32_SGXLEPUBKEYHASHn, I suppose KVM also will update guest's value to
this percpu variable after KVM writes guest's value to hardware MSR? And
host (SGX driver) need to do the same thing (check the value and write
conditionally), correct?
Thanks,
-Kai
Yes, the percpu variable is simply a cache so that the kernel doesn't have to do
four RDMSRs every time it wants to do EINIT. KVM would still maintain shadow
copies of the MSRs for each vcpu for emulating RDMSR, WRMSR and EINIT. I don't
think KVM would even need to be aware of the percpu variable, i.e. the entire
lock->(rd/wr)msr->EINIT->unlock sequence can probably be encapsulated in a
single function that is called from both the primary SGX driver and from KVM.
You are making assumption that KVM will run ENCLS on behalf of guest. :)
If we don't need to look into guest's SIGSTRUCT, EINITTOKEN, etc, then I
actually prefer to using MTF, as with MTF we don't have to do all the
remapping guest's virtual address to KVM's virtual address thing, if we
don't need to look into guest's ENCLS parameter. But if we need to look
into guest's ENCLS parameters, for example, to locate physical SECS
page, or to update physical EPC page's info (that KVM needs to
maintain), maybe we can choose running ENCLS on behalf of guest.
But if we are going to run ENCLS on behalf of guest, I think providing a
single function which does write MSR and EINIT for KVM should be a good
idea.
Thanks,
-Kai
