linux-kernel - Re: [PATCHv2] fix regression caused by e48672fa25e879f7ae21785c7efd187738139593

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D8C503D.6000607@redhat.com>
Date:	Fri, 25 Mar 2011 04:20:13 -0400
From:	Zachary Amsden <zamsden@...hat.com>
To:	Nikola Ciprich <extmaillist@...uxbox.cz>
CC:	KVM list <kvm@...r.kernel.org>,
	Linux kernel list <linux-kernel@...r.kernel.org>,
	nikola.ciprich@...uxbox.cz, Avi Kivity <avi@...hat.com>,
	Glauber Costa <glommer@...hat.com>
Subject: Re: [PATCHv2] fix regression caused by	e48672fa25e879f7ae21785c7efd187738139593

On 03/09/2011 05:36 PM, Nikola Ciprich wrote:
> commit 387b9f97750444728962b236987fbe8ee8cc4f8c moved kvm_request_guest_time_update(vcpu),
> breaking 32bit SMP guests using kvm-clock. Fix this by moving (new) clock update function
> to proper place.
>
> Signed-off-by: Nikola Ciprich<nikola.ciprich@...uxbox.cz>
> ---
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 4c27144..ba3f76f 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2101,8 +2101,8 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>   		if (check_tsc_unstable()) {
>   			kvm_x86_ops->adjust_tsc_offset(vcpu, -tsc_delta);
>   			vcpu->arch.tsc_catchup = 1;
> -			kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
>   		}
> +		kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
>   		if (vcpu->cpu != cpu)
>   			kvm_migrate_timers(vcpu);
>   		vcpu->cpu = cpu;
>
>    

So something bothers me still about this bug.  What you did correctly 
restores the old behavior - but it shouldn't be fixing a bug.

The only reason you need to schedule an update for the KVM clock area is 
if a new VCPU has been created, you have an unstable TSC.. or something 
changes the VM's kvmclock offset.

So this change could in fact be hiding an underlying bug - either an 
unstable TSC is not being properly reported, the KVM clock offset is 
being changed, we are missing a KVM clock update for secondary VCPUs - 
or something else we don't yet understand is going on.

Nikola, can you try the patch below, which reverts your change and 
attempts to fix other possible sources of the problem, and see if it 
still reproduces?

Thanks,

Zach

View attachment "kvm-regres-test.patch" of type "text/plain" (1103 bytes)