Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
From:   Paul Durrant <xadimgnik@gmail.com>
Message-ID: <45bd5778-6217-427e-8ac2-f7b997470476@xen.org>
Date:   Wed, 1 Nov 2023 11:06:25 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Reply-To: paul@xen.org
Subject: Re: [PATCH v2] KVM x86/xen: add an override for
 PVCLOCK_TSC_STABLE_BIT
Content-Language: en-US
To:     David Woodhouse <dwmw2@infradead.org>,
        Sean Christopherson <seanjc@google.com>
Cc:     Paolo Bonzini <pbonzini@redhat.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>, kvm@vger.kernel.org,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20231031115748.622578-1-paul@xen.org>
 <ZUGCPQegUeTutsrb@google.com>
 <028f629d16377f9a7e9fd87ef9564846b0ab4ed9.camel@infradead.org>
 <ZUGGqOCU7TAU6c6p@google.com>
 <3c71731a4f3390dc0c660f854e732df793d78bb4.camel@infradead.org>
Organization: Xen Project
In-Reply-To: <3c71731a4f3390dc0c660f854e732df793d78bb4.camel@infradead.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 31/10/2023 23:06, David Woodhouse wrote:
[snip]
>>                  mutex_lock(&kvm->lock);
>>                  if (!kvm->created_vcpus) {
>>                          kvm->arch.force_tsc_unstable = true;
>>                          r = 0;
>>                  }
>>                  mutex_unlock(&kvm->lock);
>>
>> So that it would be blatantly obvious that there's no race with checking a per-VM
>> flag without any lock/RCU protections.
> 
> Makes sense. Although TBH if the VMM wants to flip this bit on and off
> at runtime while the guest clocks are being updated, it deserves what
> it gets. It's not a problem for KVM.
> 

The first version of the patch that used an attribute requested a clock 
update when the attribute was set. I dropped that in this version but I 
think it'd best to re-instate it.

   Paul