From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH v2] KVM: x86: reset lapic_timer.expired_tscdeadline at
 SET_LAPIC time
Date: Mon, 20 Jun 2016 22:31:26 -0300
Message-ID: <20160621013126.GA27650@amt.cnet>
References: <20160617234126.GA24514@amt.cnet>
 <6bc78368-d559-fa09-7e77-389b0e87d695@gmail.com>
 <20160620130531.GA8139@amt.cnet>
 <87bb5b7c-ab8c-7bb4-b01d-f535eb716522@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: kvm-devel <kvm@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
To: Alan Jenkins <alan.christopher.jenkins@gmail.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:47135 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752209AbcFUBeb (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 20 Jun 2016 21:34:31 -0400
Content-Disposition: inline
In-Reply-To: <87bb5b7c-ab8c-7bb4-b01d-f535eb716522@gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Mon, Jun 20, 2016 at 04:20:56PM +0100, Alan Jenkins wrote:
> On 20/06/16 14:05, Marcelo Tosatti wrote:
> >Alan Jenkins reports hang at
> >https://bugzilla.redhat.com/show_bug.cgi?id=3D1337667,
> >due to guest TSC being set far behind than
> >lapic_timer.expired_tscdeadline, when restoring VM state
> >on top of currently active VM.
> >
> >It is not possible to disable LAPIC timer advancement
> >(by setting lapic_timer.expired_tscdeadline =3D 0), at
> >guest TSC write
>=20
> I like that it acknowledges (though only implicitly) the guest can
> trigger arbitrary lockups of host CPUs.
>=20
> >because:
> >
> >* APIC write: expiration =3D 1000.
> >* LAPIC tsc deadline code sets timer to 1000-30.
> >* Timer fires at 970.
> >* Guest writes TSC=3Dw.
> >
> >Guest fails to VM-entry to process signal to perform
> >"vmload" in userspace.
> >
> >Case 1: w > 970:
> >Guest entry can be performed.
> >
> >Case 2: w < 970:
> >Guest entry should not be performed because "An interrupt is generat=
ed
> >when the logical processor=E2=80=99s time-stamp counter equals or ex=
ceeds the
> >target value in the IA32_TSC_DEADLINE MSR."
> >
> >In case 2, hardware would not fire an interrupt.
> >
> >To fix the problem, disable timer advancement when
> >userspace sets the LAPIC state. Setting of APIC
> >resets all APIC state, including
> >any pending interrupt.
> >
> >Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> >Reported-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
>=20
> However I feel this doesn't admit (even implicitly) that host
> software (not necessarily root) can still hard-lockup the CPU. It
> depends on the sequence of operations, and the message doesn't show
> that sequence explicitly. I now understand what the sequence that
> _is_ in the message shows, but it's unfortunately distracting.
>=20
> I.e. if you restore the LAPIC first (or omit to do so at all), then
> restore the TSC deadline MSR, then the TSC MSR.
>=20
> The patch assumes that the LAPIC is restored after the MSRs so it
> can clear the incorrect value of expired_tscdeadline, right?

Yes.

> I didn't know whether this patch would work until I tested it,
> because I didn't try to nail down the exact sequence QEMU is using.

You are right about the host lockups -- sent another patch to fix that
one.

Thanks for the reports.