On 7/16/19 12:35 PM, Liran Alon wrote: > > >> On 16 Jul 2019, at 20:27, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >> >> On 16/07/19 18:56, Liran Alon wrote: >>> If the CPU performs the VMExit transition of state before doing the data read for DecodeAssist, >>> then I agree that CPL will be 0 on data-access regardless of vCPU CPL. But this also means that SMAP >>> violation should be raised based on host CR4.SMAP value and not vCPU CR4.SMAP value as KVM code checks. >>> >>> Furthermore, vCPU CPL of guest doesn’t need to be 3 in order to trigger this Errata. >> >> Under the conditions in the code, if CPL were <3 then the SMAP fault >> would have been sent to the guest. >> But I agree that if we need to >> change it to check host CR4, then the CPL of the guest should not be >> checked. > > Yep. > Well it all depends on how AMD CPU actually works. > We need some clarification from AMD but for sure the current code in KVM is not only wrong, but probably have never been tested. :P > > Looking for further clarifications from AMD before submitting v2… > When this errata is hit, the CPU will be at CPL3. From hardware point-of-view the below sequence happens: 1. CPL3 guest hits reserved bit NPT fault (MMIO access) 2. Microcode uses special opcode which attempts to read data using the CPL0 privileges. The microcode read CS:RIP, when it hits SMAP fault, it gives up and returns no instruction bytes. (Note: vCPU is still at CPL3) 3. CPU causes #VMEXIT for original fault address. The SMAP fault occurred while we are still in guest context. It will be nice to have code test example to triggers this errata. > -Liran > >> >> Paolo >> >>> It’s only important that guest page-tables maps the guest RIP as user-accessible. i.e. U/S bit in PTE set to 1. >> >
