Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
From:   Paul Durrant <xadimgnik@gmail.com>
Message-ID: <8b4fda17-07c3-4633-bf61-8b3829384c29@xen.org>
Date:   Wed, 1 Nov 2023 17:02:23 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Reply-To: paul@xen.org
Subject: Re: [PATCH v3] KVM x86/xen: add an override for
 PVCLOCK_TSC_STABLE_BIT
To:     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>,
        David Woodhouse <dwmw2@infradead.org>, kvm@vger.kernel.org,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20231101112934.631344-1-paul@xen.org>
 <ZUKAzGzEts262FqC@google.com>
Content-Language: en-US
Organization: Xen Project
In-Reply-To: <ZUKAzGzEts262FqC@google.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 01/11/2023 16:46, Sean Christopherson wrote:
> On Wed, Nov 01, 2023, Paul Durrant wrote:
>> @@ -3231,12 +3245,15 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
>>   	vcpu->hv_clock.flags = pvclock_flags;
>>   
>>   	if (vcpu->pv_time.active)
>> -		kvm_setup_guest_pvclock(v, &vcpu->pv_time, 0);
>> +		kvm_setup_guest_pvclock(v, &vcpu->pv_time, 0, false);
>> +
>>   	if (vcpu->xen.vcpu_info_cache.active)
>>   		kvm_setup_guest_pvclock(v, &vcpu->xen.vcpu_info_cache,
>> -					offsetof(struct compat_vcpu_info, time));
>> +					offsetof(struct compat_vcpu_info, time),
>> +					xen_pvclock_tsc_unstable);
>>   	if (vcpu->xen.vcpu_time_info_cache.active)
>> -		kvm_setup_guest_pvclock(v, &vcpu->xen.vcpu_time_info_cache, 0);
>> +		kvm_setup_guest_pvclock(v, &vcpu->xen.vcpu_time_info_cache, 0,
>> +					xen_pvclock_tsc_unstable);
>>   	kvm_hv_setup_tsc_page(v->kvm, &vcpu->hv_clock);
>>   	return 0;
> 
> Please rebase, this conflicts with commit ee11ab6bb04e ("KVM: X86: Reduce size of
> kvm_vcpu_arch structure when CONFIG_KVM_XEN=n").  I can solve the conflict, but
> I really shouldn't have to.
> 
> Also, your version of git should support --base, which makes life much easier for
> others when non-trivial conflicts are encountered.  From maintainer-kvm-x86.rst:
> 
>   : Git Base
>   : ~~~~~~~~
>   : If you are using git version 2.9.0 or later (Googlers, this is all of you!),
>   : use ``git format-patch`` with the ``--base`` flag to automatically include the
>   : base tree information in the generated patches.
>   :
>   : Note, ``--base=auto`` works as expected if and only if a branch's upstream is
>   : set to the base topic branch, e.g. it will do the wrong thing if your upstream
>   : is set to your personal repository for backup purposes.  An alternative "auto"
>   : solution is to derive the names of your development branches based on their
>   : KVM x86 topic, and feed that into ``--base``.  E.g. ``x86/pmu/my_branch_name``,
>   : and then write a small wrapper to extract ``pmu`` from the current branch name
>   : to yield ``--base=x/pmu``, where ``x`` is whatever name your repository uses to
>   : track the KVM x86 remote.
> 

Ok, I'll sort that out. Thanks for the tip.

>> @@ -4531,7 +4548,8 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>   		    KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL |
>>   		    KVM_XEN_HVM_CONFIG_SHARED_INFO |
>>   		    KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL |
>> -		    KVM_XEN_HVM_CONFIG_EVTCHN_SEND;
>> +		    KVM_XEN_HVM_CONFIG_EVTCHN_SEND |
>> +		    KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE;
>>   		if (sched_info_on())
>>   			r |= KVM_XEN_HVM_CONFIG_RUNSTATE |
>>   			     KVM_XEN_HVM_CONFIG_RUNSTATE_UPDATE_FLAG;
>> diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
>> index 40edf4d1974c..7699d94f190b 100644
>> --- a/arch/x86/kvm/xen.c
>> +++ b/arch/x86/kvm/xen.c
>> @@ -1111,9 +1111,12 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)
>>   
>>   int kvm_xen_hvm_config(struct kvm *kvm, struct kvm_xen_hvm_config *xhc)
>>   {
>> +	bool update_pvclock = false;
>> +
>>   	/* Only some feature flags need to be *enabled* by userspace */
>>   	u32 permitted_flags = KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL |
>> -		KVM_XEN_HVM_CONFIG_EVTCHN_SEND;
>> +		KVM_XEN_HVM_CONFIG_EVTCHN_SEND |
>> +		KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE;
>>   
>>   	if (xhc->flags & ~permitted_flags)
>>   		return -EINVAL;
>> @@ -1134,9 +1137,19 @@ int kvm_xen_hvm_config(struct kvm *kvm, struct kvm_xen_hvm_config *xhc)
>>   	else if (!xhc->msr && kvm->arch.xen_hvm_config.msr)
>>   		static_branch_slow_dec_deferred(&kvm_xen_enabled);
>>   
>> +	if ((kvm->arch.xen_hvm_config.flags &
>> +	     KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE) !=
>> +	    (xhc->flags &
>> +	     KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE))
>> +		update_pvclock = true;
> 
> Rather than a boolean and the above, which is a bit hard to parse, what about
> taking a snapshot of the old flags and then doing an XOR?
> 
> 	/* Only some feature flags need to be *enabled* by userspace */
> 	u32 permitted_flags = KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL |
> 		KVM_XEN_HVM_CONFIG_EVTCHN_SEND |
> 		KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE;
> 	u32 old_flags;
> 
> 	if (xhc->flags & ~permitted_flags)
> 		return -EINVAL;
> 
> 	/*
> 	 * With hypercall interception the kernel generates its own
> 	 * hypercall page so it must not be provided.
> 	 */
> 	if ((xhc->flags & KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL) &&
> 	    (xhc->blob_addr_32 || xhc->blob_addr_64 ||
> 	     xhc->blob_size_32 || xhc->blob_size_64))
> 		return -EINVAL;
> 
> 	mutex_lock(&kvm->arch.xen.xen_lock);
> 
> 	if (xhc->msr && !kvm->arch.xen_hvm_config.msr)
> 		static_branch_inc(&kvm_xen_enabled.key);
> 	else if (!xhc->msr && kvm->arch.xen_hvm_config.msr)
> 		static_branch_slow_dec_deferred(&kvm_xen_enabled);
> 
> 	old_flags = kvm->arch.xen_hvm_config.flags;
> 	memcpy(&kvm->arch.xen_hvm_config, xhc, sizeof(*xhc));
> 
> 	mutex_unlock(&kvm->arch.xen.xen_lock);
> 
> 	if ((old_flags ^ xhc->flags) & KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE)
> 		kvm_make_all_cpus_request(kvm, KVM_REQ_CLOCK_UPDATE);
> 
> 	return 0;

Sure, I can do it that way if you prefer.

   Paul