Hi Paolo, On 2/13/19 8:11 AM, Paolo Bonzini wrote: > On 12/02/19 18:41, Jim Mattson wrote: >> On Tue, Feb 12, 2019 at 6:44 AM Singh, Brijesh <brijesh.singh@xxxxxxx> wrote: >>> >>> Errata#1090: >>> >>> On a nested data page fault when CR.SMAP=1 and the guest data read >>> generates a SMAP violation, GuestInstrBytes field of the VMCB on a >>> VMEXIT will incorrectly return 0h instead the correct guest >>> instruction bytes . >>> >>> Recommend Workaround: >>> >>> To determine what instruction the guest was executing the hypervisor >>> will have to decode the instruction at the instruction pointer. >>> >>> The recommended workaround can not be implemented for the SEV >>> guest because guest memory is encrypted with the guest specific key, >>> and instruction decoder will not be able to decode the instruction >>> bytes. If we hit this errata in the SEV guest then inject #GP into >>> the guest and log the message. > > Actually this is not the workaround that KVM is implementing; KVM is > simply retrying the instruction after fixing the page fault. This would > cause an infinite loop in the guest if the instruction is actually MMIO, > however in that case KVM will get an RSVD page fault rather than a SMAP > page fault and the errata would not be triggered. So why is this patch > needed? > KVM is not getting a SMAP page fault. The HW gets a SMAP fault when trying to fetch the instruction bytes, 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(...)). thanks Brijesh
