On Thu, May 18, 2017 at 1:14 AM, Huang, Kai <kai.huang@xxxxxxxxxxxxxxx> wrote:
> 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.
After thinking about this a bit, I don't see how MTF helps.
Currently, KVM works kind of like this:
local_irq_disable();
set up stuff;
VMRESUME;
restore some host state;
local_irq_enable();
If the guest is going to run with the EINIT-exiting bit clear, the
only way I see this working is to modify KVM along the lines of:
local_irq_disable();
set up stuff;
if (condition here) {
WRMSR to SGXLEPUBKEYHASH;
update percpu shadow copyl
clear EINIT-exiting bit;
} else {
set EINIT-exiting bit;
}
VMRESUME;
restore some host state;
local_irq_enable();
where "condition here" might be something like "the last VMRESUME
exited due to EINIT".
I don't see how MTF helps much. And if I were the KVM maintainer, I
would probably prefer to trap EINIT instead of adding a special case
to the main vm entry code.
