From: Paolo Bonzini <pbonzini@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm-devel <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>
Subject: Re: KVM: x86: update masterclock when kvmclock_offset is calculated
Date: Tue, 03 Sep 2013 12:42:40 +0200 [thread overview]
Message-ID: <5225BD20.1000902@redhat.com> (raw)
In-Reply-To: <20130903030351.GA3167@amt.cnet>
Il 03/09/2013 05:03, Marcelo Tosatti ha scritto:
> > Here is the code I was thinking of:
> >
> > spin_lock(&ka->pvclock_gtod_sync_lock);
> > make_all_cpus_request(kvm, KVM_REQ_CLOCK_UPDATE);
> >
> > /*
> > * No guest entries from this point: VCPUs will be spinning
> > * on pvclock_gtod_sync_lock in kvm_guest_time_update.
> > */
> > pvclock_update_vm_gtod_copy(kvm);
> >
> > /*
> > * Let kvm_guest_time_update continue: entering the guest
> > * is now allowed too.
> > */
> > spin_unlock(&ka->pvclock_gtod_sync_lock);
> >
> > KVM_REQ_CLOCK_UPDATE is used to cancel guest entry and execute
> > kvm_guest_time_update. But kvm_guest_time_update will spin on
> > pvclock_gtod_sync_lock until pvclock_update_vm_gtod_copy exits and
> > kvm_gen_update_masterclock releases the spinlock.
>
> Not safe because there are places which set KVM_REQ_CLOCK_UPDATE without
> kicking target vcpu out of guest mode. Unless you use a modified
> make_all_cpus_request.
make_all_cpus_request does force an exit, even if the bit is already set
in vcpus->requests. But maybe here is where I'm missing something.
> The point of REQ_MCLOCK_INPROGRESS request is to guarantee that the
> following is not possible:
>
> - 2 vcpus in guest mode with per-vcpu kvmclock areas with
> different {system_timestamp, tsc_offset} values.
Understood.
> To achieve that:
>
> - Kick all vcpus out of guest mode (via a request bit that can't be
> cleared).
> - Update the {system_timestamp, tsc_offset} values.
> - Clear the request bit.
After make_all_cpus_request, all VCPUs will be out of guest mode, and
the request bit will not be cleared until pvclock_gtod_sync_lock is
released.
Paolo
next prev parent reply other threads:[~2013-09-03 10:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-20 18:20 KVM: x86: update masterclock when kvmclock_offset is calculated Marcelo Tosatti
2013-08-22 17:05 ` Paolo Bonzini
2013-08-23 10:00 ` Paolo Bonzini
2013-08-28 2:55 ` KVM: x86: update masterclock when kvmclock_offset is calculated (v2) Marcelo Tosatti
2013-08-28 14:47 ` Gleb Natapov
2013-08-28 2:55 ` KVM: x86: update masterclock when kvmclock_offset is calculated Marcelo Tosatti
2013-08-28 2:52 ` Marcelo Tosatti
2013-08-28 12:37 ` Paolo Bonzini
2013-09-03 3:03 ` Marcelo Tosatti
2013-09-03 10:42 ` Paolo Bonzini [this message]
2013-09-03 13:56 ` Marcelo Tosatti
2013-09-03 14:20 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5225BD20.1000902@redhat.com \
--to=pbonzini@redhat.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.