On 21/06/2017 14:36, Mihai Donțu wrote: > The entire mechanism for altering spte-s will need a separate > discussion, because right now it interferes with other mmu features > like dirty page logging and possibly other that I might not be aware > of. Okay, this is the stuff that should be put in the cover letter. The current cover letter instead is an attempt at documentation that should, of course, be in Documentation/ instead. :) I think the right way to do it is to rebuild the MMU when the radix tree is modified, with KVM_REQ_MMU_SYNC (or maybe even kvm_mmu_reset_context is enough, I am not sure). kvm_mmu_get_page can modify role.access according to the result of the radix tree lookup. When you make the page read-only, the role (which is part of the hash key) changes and the EPT tables will also be made read-only. Paolo > The present code merely illustrates what we're really trying to > achieve: control the page permissions in the shadow page tables. The > mechanics are quite simple: while a VCPU is paused the introspection > tool creates a list of all spte's it wants to alter and then it > unpauses the VCPU which, on its wait back into the guest, walks the > list and applies the changes. This list-based approach is used because > sometimes accessing spte-s requires access to qemu's address space > which is tricky to do when the introspection tool runs as a separate > process. We tried using something on top of switch_mm() but it proved > unreliable. It also requires exporting some very deep x86-specific data > in order to build kvm-intel.ko. > >> How does this work when multiple VCPUs are running with different MMU >> roles? One VCPU is emptying the access_list for all, but >> kvm_mmu_set_spte is using for_each_shadow_entry per-VCPU. > Indeed, here we assume all VCPU-s' spt pointers are loaded with the > same address. A correct approach would iterate over all vCPU-s and I > suspect it would need to be a bit more complex with Intel's multiple > EPT views. >
