On 15/02/2017 23:49, Jim Mattson wrote: >> 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... Either a new ioctl, or KVM_ENABLE_CAP to enable parsing the padding bytes. The format of struct kvm_translation is a bit inflexible, so I think a new ioctl would be better. BTW, have you seen this patent: https://www.google.com/patents/US20150378633? Implemnting this for nested EPT would complicate the MMU quite a lot. Paolo
