On 2011-01-28 20:48, Glauber Costa wrote: > Up to know, we were relying on guest cooperation to turn off kvmclock. > I just realized that even though this is fine and nice, a more robust > method is to (also) turn it off on vcpu_reset on the hypervisor side. > This will protect us against reboots, and we don't expect the guest > to reset its cpu during normal operation anyway. > > Signed-off-by: Glauber Costa <[email protected]> > --- > arch/x86/kvm/x86.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index bcc0efc..38b55b3 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -5878,6 +5878,11 @@ int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu) > kvm_make_request(KVM_REQ_EVENT, vcpu); > vcpu->arch.apf.msr_val = 0; > > + if (vcpu->arch.time_page) { > + kvm_release_page_dirty(vcpu->arch.time_page); > + vcpu->arch.time_page = NULL; > + } > +
kvm_arch_vcpu_reset is only called on vcpu setup and when it receives a sipi (provided in-kernel irqchip is in use). If you want this page to be consistently reset on guest reboot, you have to trigger this from user space. But I thought we are doing this already in qemu, don't we? Jan
signature.asc
Description: OpenPGP digital signature
