On 02/08/2017 13:52, Mihai Donțu wrote:
> I think it might help to distinguish two situations in which we require
> the guest _or_ a single vCPU to be paused. Our initial KVMI_PAUSE_GUEST
> command can be translated into a qemu pause. In our particular usecase
> we made special arrangements to call it as few times as possible
> assuming it's very costly. The other is needed only by the internal KVM
> code for situations similar to:
>
> kvm_pause_vcpu(vcpu);
> vcpu_load(vcpu);
> kvm_arch_vcpu_ioctl_get_regs(vcpu, regs);
> vcpu_put(vcpu);
> kvm_unpause_vcpu(vcpu);
>
> or more generally put, for accesses that involve the vCPU state
> (registers, MSR-s, exceptions etc.), no guest memory involved.
>
> Here kvm_pause_vcpu() will only pull the vCPU out of the guest and, if
> so, make it somehow available for quick re-entry with
> kvm_unpause_vcpu(). If said vCPU is already out, then the function will
> be a no-op. Obviously, kvm_{pause,unpause}_vcpu() will do nothing if
> we're currently handling an event or one is pending.
Understood. The issue is that there is an inherent race between
anything userspace is doing and get_regs. What are the cases where you
need to get regs or similar outside an event?
> One exception that might have a better solution is:
>
> kvm_pause_all_vcpus(kvm);
> kvm_set_page_access(kvm, gfn); /* pause for get too? */
> kvm_unpause_all_vcpus(kvm);
>
> There might be a way to make the change and then IPI all vCPU-s without
> pulling them out of the guest.
For that I think KVMI should define a VM-wide "mask" layered over the
actual memory map permissions. Such a command can be implemented
relatively easily by hooking into the callers of __gfn_to_pfn_memslot
and kvm_vcpu_gfn_to_hva_prot.
Paolo
