On 2/13/19 10:44 AM, Paolo Bonzini wrote:
> On 13/02/19 17:40, Singh, Brijesh wrote:
>>
>> KVM is not getting a SMAP page fault. The HW gets a SMAP fault when
>> trying to fetch the instruction bytes
>
> How does the hardware get a SMAP fault when trying to fetch
> instructions? SMAP faults are only generated for data accesses, not
> instructions. Now I'm even more confused. :)
>
I was hoping to clarify instead of causing more confusion :)
Here's is how it works:
1. Guest does the MMIO access which causes a rsvd page fault
2. Hardware processes this as a VMEXIT
3. During the processing, hardware attempts to read the instruction
bytes. This is done by issuing a data read request from the RIP
that the guest was at.
4. The result of these reads are then stored in the VMCB.
So in step #3 there can be a SMAP fault because internally the CPU
is doing a data read from the RIP to get these bytes. Hardware didn't
save them from the actual instruction execution or anything, it
actually go and re-read them, which is why this can cause a SMAP
fault.
> Paolo
>
> , and that fault is ignored (and
>> instead the ucode just doesn't save any instruction bytes). The fault
>> code to KVM is the RSVD. While handling the RSVD fault, KVM may come to
>> the code path which requires instruction emulation. At this time we will
>> check to see if SMAP was enabled and insn_len is zero. If so, we are
>> hitting this errata. If we skip the emulation and restart the guest
>> then in this particular case we will get the *same* fault again and
>> enter into infinite loop. In case of non SEV, we can workaround it by
>> letting the KVM read the instruction bytes from the guest RIP. But
>> in case of SEV we will have no choice other than requesting to restart
>> and thus causing guest an infinite loop. In SEV, my attempt was to
>> detect this errata and log it and request the SHUTDOWN of the
>> guest so that we continue further (in v1 I am doing #GP instead
>> of the SHUTDOWN request, based on Jim's comment I am switching to use
>> kvm_make_request(...)).
>
