From: Marcelo Tosatti <mtosatti@redhat.com>
To: Alan Jenkins <alan.christopher.jenkins@gmail.com>
Cc: kvm-devel <kvm@vger.kernel.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: KVM: x86: reset lapic_timer.expired_tscdeadline at SET_LAPIC time
Date: Mon, 20 Jun 2016 10:11:58 -0300 [thread overview]
Message-ID: <20160620131157.GA7470@amt.cnet> (raw)
In-Reply-To: <6bc78368-d559-fa09-7e77-389b0e87d695@gmail.com>
On Sat, Jun 18, 2016 at 02:43:51PM +0100, Alan Jenkins wrote:
> On 18/06/2016, Marcelo Tosatti <mtosatti@redhat.com> wrote:
> >
> >Alan Jenkins reports hang at
> >https://bugzilla.redhat.com/show_bug.cgi?id=1337667.
> >
> >* APIC write: expiration = 1000.
> >* LAPIC tsc deadline code sets timer to 1000-30.
> >* Timer fires at 970.
> >* Guest writes TSC=w.
> >
> >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 generated
> >when the logical processor’s time-stamp counter equals or exceeds the
> >target value in the IA32_TSC_DEADLINE MSR."
> >
> >Setting of APIC test resets all APIC state, including
> >any pending interrupts.
> >
> >Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> >
> >diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> >index ea306ad..89be6e9 100644
> >--- a/arch/x86/kvm/x86.c
> >+++ b/arch/x86/kvm/x86.c
> >@@ -2991,6 +2991,7 @@ static int kvm_vcpu_ioctl_set_lapic(struct kvm_vcpu
> >*vcpu,
> > {
> > kvm_apic_post_state_restore(vcpu, s);
> > update_cr8_intercept(vcpu);
> >+ vcpu->arch.apic->lapic_timer.expired_tscdeadline = 0;
> >
> > return 0;
> > }
>
> Hi
>
> I'm happy to check my own test if this is considered a solution.
> (And apologies for how my own efforts go... flailing around and not
> always communicating effectively...)
Your report had many details.
> 1) I think the commit message could be improved. Specifically it
> says the problem is due to TSC write, then that we need to fix LAPIC
> reset. It doesn't say what the connection is between the two.
Right.
> (I.e. you would have to read the bug report, & then realize that it
> _happens_ to involve a LAPIC state restore as well, because it's
> triggered by reloading the entire VM state from a snapshot)
>
> Doing so might make the intention of this commit clearer. I've been
> trying to work out a high quality fix, which prevents the lockups
> revealed by this case. I think this commit would fix my bug nicely,
> but it doesn't help e.g. if the LAPIC restore was omitted from the
> sequence.
>
> (Both TSC and the value of TSC deadline are set by MSRs, not by
> writing to the LAPIC. So I don't think the LAPIC state restore is
> necessary to trigger the issue).
>
>
> 2) If this approach is considered expedient, I have two comments -
>
> i) isn't it better to set lapic_timer.expired_tscdeadline in
> lapic.c, i.e. in apic_post_state_restore() ?
>
> ii) then, wouldn't it be more correct to set it between
> hrtimer_cancel() and start_apic_timer()? It doesn't sound right to
> clear expired_tscdeadline, in case it was set immediately by
> start_apic_timer()
>
> Alan
Advancing the timer expiration should only be necessary on
guest initiated writes. Lets improve the commit message.
Can you confirm the patch fixes your problem?
next prev parent reply other threads:[~2016-06-20 13:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-17 23:41 KVM: x86: reset lapic_timer.expired_tscdeadline at SET_LAPIC time Marcelo Tosatti
2016-06-18 13:43 ` Alan Jenkins
2016-06-20 13:05 ` [PATCH v2] " Marcelo Tosatti
2016-06-20 15:22 ` Alan Jenkins
[not found] ` <87bb5b7c-ab8c-7bb4-b01d-f535eb716522@gmail.com>
2016-06-21 1:31 ` Marcelo Tosatti
2016-06-21 7:50 ` Paolo Bonzini
2016-06-21 11:35 ` Marcelo Tosatti
2016-06-21 11:37 ` Paolo Bonzini
2016-06-20 13:11 ` Marcelo Tosatti [this message]
2016-06-20 15:22 ` Alan Jenkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160620131157.GA7470@amt.cnet \
--to=mtosatti@redhat.com \
--cc=alan.christopher.jenkins@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox