On Wed, Feb 15, 2017 at 2:05 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > On 15/02/2017 23:00, Jim Mattson wrote: >> Yes, I see that this works for the in-kernel instruction emulator. My >> question was regarding a hypothetical user-space instruction emulator. I >> can see how a #PF resulting from KVM_TRANSLATE could be injected with >> KVM_SET_VCPU_EVENTS (if KVM_TRANSLATE was forthcoming with the error code, >> anyway). However, what if the KVM_TRANSLATE ioctl were to fail because of >> an EPT violation? I don't see an ioctl that would allow userspace to inject >> a VM-exit event (complete with exit reason, exit qualification, and all of >> the other VM-exit information fields that might be relevant.) Or are you >> saying that simply encountering the EPT violation while >> trying to answer a KVM_TRANSLATE request would induce the VM-exit? > > I think it should, yes. There are other limitations of KVM_TRANSLATE > (it always assumes CPL=0 for example) but the same logic would apply to > KVM_TRANSLATE and to the in-kernel emulator. Since KVM_TRANSLATE doesn't supply access mode, the exit qualification would be deficient in more than the final access/paging-structure-entry bit you reference below. Is it possible to fix this ioctl without breaking backwards compatibility? Can existing userspace code be expected to fill the pad[] bytes of the kvm_translate structure with 0? (There doesn't appear to be any enforcement of this, so I'm assuming not.) Between this and the CPL==0 assumption, KVM_TRANSLATE seems like a non-starter. But perhaps a new and improved API in the same vein... > Paolo > >>> One thing where we're lacking a bit is that translate_nested_gpa should >>> have an argument for "translating translated guest address" vs. >>> "translating guest page structure address", in order to set EXITINFO or >>> exit qualification correctly. This is incorrect right now. >>> >>> Paolo >>
