All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Hollis Blanchard <hollis-yUx37fBWTUITNcAmw9vGhQ@public.gmane.org>
Cc: kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/3] Improve DEC handling
Date: Mon, 21 Dec 2009 18:19:10 +0000	[thread overview]
Message-ID: <4B2FBC1E.6020206@suse.de> (raw)
In-Reply-To: <fb412d760912211013w265d3d30i99498ab136a15e00-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hollis Blanchard wrote:
> On Mon, Dec 21, 2009 at 6:22 AM, Alexander Graf <agraf@suse.de> wrote:
>   
>> We treated the DEC interrupt like an edge based one. This is not true for
>> Book3s. The DEC keeps firing until mtdec is issued again and thus clears
>> the interrupt line.
>>     
>
> That's not quite right. The decrementer keeps firing until the top bit
> is cleared, i.e. with mtdec. However, not *every* mtdec clears it.
>   

Right, that's we we fire a dec interrupt off whenever we mtdec with the
top bit set.

> (Also, I'm pretty sure this varies between Book 3S implementations,
> e.g. 970 behaves differently than POWERn. I don't remember specific
> values of <n> though, and I could be misremembering...)
>   

IIRC only the embedded cores were different. But I could be wrong. How
do I find out?

> So is this the failure mode?
> - a decrementer interrupt is delivered
> - guest does *not* issue mtdec to clear it (ppc64's lazy interrupt disabling?)
> - guest expects a second decrementer interrupt, but KVM doesn't deliver one
>
> In that case, it seems like the real fix would be something like this:
>
>  void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
>  {
>  	unsigned long dec_nsec;
>
>  	pr_debug("mtDEC: %x\n", vcpu->arch.dec);
>  #ifdef CONFIG_PPC64
>  	/* POWER4+ triggers a dec interrupt if the value is < 0 */
>  	if (vcpu->arch.dec & 0x80000000) {
>  		hrtimer_try_to_cancel(&vcpu->arch.dec_timer);
>  		kvmppc_core_queue_dec(vcpu);
> +		/* keep queuing interrupts until guest clears high MSR bit */
> + 		hrtimer_start(&vcpu->arch.dec_timer, ktime_set(0, 100),
> + 			      HRTIMER_MODE_REL);
>   

This code path is only triggered when the guest mtdecs with a negative
value.

But I understand what you're trying to suggest and I think it's a bad
idea. We don't want to poll the guest for interrupt enablement.

On a real CPU the DEC interrupt keeps being active when the DEC register
is negative. And that's exactly what this patch implements, no? That way
we are automatically event-based and everyone's happy.

Alex

WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
To: Hollis Blanchard <hollis-yUx37fBWTUITNcAmw9vGhQ@public.gmane.org>
Cc: kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/3] Improve DEC handling
Date: Mon, 21 Dec 2009 19:19:10 +0100	[thread overview]
Message-ID: <4B2FBC1E.6020206@suse.de> (raw)
In-Reply-To: <fb412d760912211013w265d3d30i99498ab136a15e00-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hollis Blanchard wrote:
> On Mon, Dec 21, 2009 at 6:22 AM, Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org> wrote:
>   
>> We treated the DEC interrupt like an edge based one. This is not true for
>> Book3s. The DEC keeps firing until mtdec is issued again and thus clears
>> the interrupt line.
>>     
>
> That's not quite right. The decrementer keeps firing until the top bit
> is cleared, i.e. with mtdec. However, not *every* mtdec clears it.
>   

Right, that's we we fire a dec interrupt off whenever we mtdec with the
top bit set.

> (Also, I'm pretty sure this varies between Book 3S implementations,
> e.g. 970 behaves differently than POWERn. I don't remember specific
> values of <n> though, and I could be misremembering...)
>   

IIRC only the embedded cores were different. But I could be wrong. How
do I find out?

> So is this the failure mode?
> - a decrementer interrupt is delivered
> - guest does *not* issue mtdec to clear it (ppc64's lazy interrupt disabling?)
> - guest expects a second decrementer interrupt, but KVM doesn't deliver one
>
> In that case, it seems like the real fix would be something like this:
>
>  void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
>  {
>  	unsigned long dec_nsec;
>
>  	pr_debug("mtDEC: %x\n", vcpu->arch.dec);
>  #ifdef CONFIG_PPC64
>  	/* POWER4+ triggers a dec interrupt if the value is < 0 */
>  	if (vcpu->arch.dec & 0x80000000) {
>  		hrtimer_try_to_cancel(&vcpu->arch.dec_timer);
>  		kvmppc_core_queue_dec(vcpu);
> +		/* keep queuing interrupts until guest clears high MSR bit */
> + 		hrtimer_start(&vcpu->arch.dec_timer, ktime_set(0, 100),
> + 			      HRTIMER_MODE_REL);
>   

This code path is only triggered when the guest mtdecs with a negative
value.

But I understand what you're trying to suggest and I think it's a bad
idea. We don't want to poll the guest for interrupt enablement.

On a real CPU the DEC interrupt keeps being active when the DEC register
is negative. And that's exactly what this patch implements, no? That way
we are automatically event-based and everyone's happy.

Alex

  parent reply	other threads:[~2009-12-21 18:19 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-21 14:22 [PATCH 0/3] Improve Decrementor Implementation Alexander Graf
2009-12-21 14:22 ` Alexander Graf
2009-12-21 14:22 ` [PATCH 1/3] Move vector to irqprio resolving to separate function Alexander Graf
2009-12-21 14:22   ` Alexander Graf
2009-12-21 14:22 ` [PATCH 2/3] Improve DEC handling Alexander Graf
     [not found]   ` <1261405373-8008-3-git-send-email-agraf-l3A5Bk7waGM@public.gmane.org>
2009-12-21 18:13     ` Hollis Blanchard
2009-12-21 18:13       ` Hollis Blanchard
     [not found]       ` <fb412d760912211013w265d3d30i99498ab136a15e00-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-12-21 18:17         ` Hollis Blanchard
2009-12-21 18:17           ` Hollis Blanchard
     [not found]           ` <fb412d760912211017i3f47fce2oc3b67c9c5c645b6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-12-21 18:20             ` Alexander Graf
2009-12-21 18:20               ` Alexander Graf
     [not found]               ` <4B2FBC74.3080705-l3A5Bk7waGM@public.gmane.org>
2009-12-21 19:04                 ` Hollis Blanchard
2009-12-21 19:04                   ` Hollis Blanchard
2009-12-21 18:19         ` Alexander Graf [this message]
2009-12-21 18:19           ` Alexander Graf
2009-12-21 14:22 ` Alexander Graf
2009-12-21 14:22 ` [PATCH 3/3] Remove AGGRESSIVE_DEC Alexander Graf
2009-12-21 14:22   ` Alexander Graf
2009-12-21 19:21 ` [PATCH 0/3] Improve Decrementor Implementation v2 Alexander Graf
2009-12-21 19:21   ` Alexander Graf
2009-12-21 23:21   ` Hollis Blanchard
2009-12-21 23:21     ` Hollis Blanchard
     [not found]   ` <1261423285-12715-1-git-send-email-agraf-l3A5Bk7waGM@public.gmane.org>
2009-12-21 19:21     ` [PATCH 1/3] Move vector to irqprio resolving to separate function Alexander Graf
2009-12-21 19:21       ` Alexander Graf
2009-12-21 19:21     ` [PATCH 2/3] Improve DEC handling Alexander Graf
2009-12-21 19:21       ` Alexander Graf
2009-12-21 19:21     ` [PATCH 3/3] Remove AGGRESSIVE_DEC Alexander Graf
2009-12-21 19:21       ` Alexander Graf
2009-12-22 10:04     ` [PATCH 0/3] Improve Decrementor Implementation v2 Avi Kivity
2009-12-22 10:04       ` Avi Kivity

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=4B2FBC1E.6020206@suse.de \
    --to=agraf@suse.de \
    --cc=hollis-yUx37fBWTUITNcAmw9vGhQ@public.gmane.org \
    --cc=kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.