From: Marcelo Tosatti <mtosatti@redhat.com>
To: Roman Kagan <rkagan@virtuozzo.com>,
kvm@vger.kernel.org, "Denis V. Lunev" <den@openvz.org>,
Owen Hofmann <osh@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] x86/kvm: fix condition to update kvm master clocks
Date: Fri, 17 Jun 2016 19:21:21 -0300 [thread overview]
Message-ID: <20160617222119.GA15883@amt.cnet> (raw)
In-Reply-To: <20160613171929.exgvqiw5hmnza2rp@rkaganb.sw.ru>
On Mon, Jun 13, 2016 at 08:19:30PM +0300, Roman Kagan wrote:
> While we're at this:
>
> According to the comments in the code, the purpose of the masterclock
> scheme is to prevent any vCPU from seeing an outdated hv_clock of
> another vCPU.
It prevents two vcpus from using different hv_clocks:
"
* To avoid that problem, do not allow visibility of distinct
* system_timestamp/tsc_timestamp values simultaneously: use a master
* copy of host monotonic time values. Update that master copy
* in lockstep.
"
> However I'm missing how that is achieved. AFAICS the guest entry is
> allowed as soon as all vCPUs are kicked from guest with
> KVM_REQ_CLOCK_UPDATE set; what stops one vCPU from processing it and
> entering the guest before another vCPU even started updating its
> hv_clock?
static void kvm_gen_update_masterclock(struct kvm *kvm)
{
#ifdef CONFIG_X86_64
int i;
struct kvm_vcpu *vcpu;
struct kvm_arch *ka = &kvm->arch;
spin_lock(&ka->pvclock_gtod_sync_lock);
kvm_make_mclock_inprogress_request(kvm);
/* no guest entries from this point */
pvclock_update_vm_gtod_copy(kvm);
kvm_for_each_vcpu(i, vcpu, kvm)
kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
/* guest entries allowed */
kvm_for_each_vcpu(i, vcpu, kvm)
clear_bit(KVM_REQ_MCLOCK_INPROGRESS, &vcpu->requests);
spin_unlock(&ka->pvclock_gtod_sync_lock);
#endif
}
next prev parent reply other threads:[~2016-06-17 23:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-26 14:49 [PATCH] x86/kvm: fix condition to update kvm master clocks Roman Kagan
2016-05-26 20:19 ` Radim Krčmář
2016-05-27 17:28 ` Roman Kagan
2016-05-27 18:11 ` Radim Krčmář
2016-05-27 18:46 ` Roman Kagan
2016-05-27 19:29 ` Radim Krčmář
2016-05-29 23:38 ` Marcelo Tosatti
2016-06-09 3:27 ` Marcelo Tosatti
2016-06-09 3:45 ` Marcelo Tosatti
2016-06-09 12:09 ` Roman Kagan
2016-06-09 18:25 ` Marcelo Tosatti
2016-06-09 19:19 ` Roman Kagan
2016-06-13 17:07 ` Roman Kagan
2016-06-14 22:11 ` Marcelo Tosatti
2016-06-13 17:19 ` Roman Kagan
2016-06-17 22:21 ` Marcelo Tosatti [this message]
2016-06-20 17:22 ` Roman Kagan
2016-06-20 21:29 ` Marcelo Tosatti
2016-06-21 14:40 ` Roman Kagan
2016-06-21 21:28 ` Marcelo Tosatti
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=20160617222119.GA15883@amt.cnet \
--to=mtosatti@redhat.com \
--cc=den@openvz.org \
--cc=kvm@vger.kernel.org \
--cc=osh@google.com \
--cc=pbonzini@redhat.com \
--cc=rkagan@virtuozzo.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.