From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: KVM: x86: update masterclock when kvmclock_offset is calculated Date: Tue, 03 Sep 2013 16:20:49 +0200 Message-ID: <5225F041.5070003@redhat.com> References: <20130820182012.GA814@amt.cnet> <521644D0.9050902@redhat.com> <20130828025243.GA13653@amt.cnet> <521DEF00.2030200@redhat.com> <20130903030351.GA3167@amt.cnet> <5225BD20.1000902@redhat.com> <20130903135559.GA17834@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm-devel , Gleb Natapov To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45815 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753275Ab3ICOUt (ORCPT ); Tue, 3 Sep 2013 10:20:49 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r83EKnYc024579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 3 Sep 2013 10:20:49 -0400 In-Reply-To: <20130903135559.GA17834@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: Il 03/09/2013 15:56, Marcelo Tosatti ha scritto: >>> 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. > > It seems more obfuscated to rely on an implicit pvclock_gtod_sync_lock > blocking than an explicit request bit that can't be cleared, but perhaps > thats personal opinion. Yes, this gets dangerously close to personal opinion territory. :) > OTOH, you can also argue that the request bit abuses the vcpu->requests > request mechanism, because there is not a request in fact (it only > blocks guest entry). The busy-wait is a bit ugly, but otherwise it's fine. > If you have reasons to update, and you are sure its safe, feel > free to modify it. No reason yet apart from removing a few lines of code, but thanks for discussing this. If you want to do the seqlock change for pvclock_gtod_sync_lock, I'll be glad to review the patch. Paolo