From: Alexander Graf <agraf@suse.de>
To: Paul Mackerras <paulus@samba.org>, linuxppc-dev@ozlabs.org
Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] powerpc: powernv: Return to cpu offline loop when finished in KVM guest
Date: Wed, 17 Dec 2014 12:40:46 +0000 [thread overview]
Message-ID: <549179CE.7030100@suse.de> (raw)
In-Reply-To: <20141203034840.GA612@iris.ozlabs.ibm.com>
On 03.12.14 04:48, Paul Mackerras wrote:
> When a secondary hardware thread has finished running a KVM guest, we
> currently put that thread into nap mode using a nap instruction in
> the KVM code. This changes the code so that instead of doing a nap
> instruction directly, we instead cause the call to power7_nap() that
> put the thread into nap mode to return. The reason for doing this is
> to avoid having the KVM code having to know what low-power mode to
> put the thread into.
>
> In the case of a secondary thread used to run a KVM guest, the thread
> will be offline from the point of view of the host kernel, and the
> relevant power7_nap() call is the one in pnv_smp_cpu_disable().
> In this case we don't want to clear pending IPIs in the offline loop
> in that function, since that might cause us to miss the wakeup for
> the next time the thread needs to run a guest. To tell whether or
> not to clear the interrupt, we use the SRR1 value returned from
> power7_nap(), and check if it indicates an external interrupt. We
> arrange that the return from power7_nap() when we have finished running
> a guest returns 0, so pending interrupts don't get flushed in that
> case.
>
> Note that it is important a secondary thread that has finished
> executing in the guest, or that didn't have a guest to run, should
> not return to power7_nap's caller while the kvm_hstate.hwthread_req
> flag in the PACA is non-zero, because the return from power7_nap
> will reenable the MMU, and the MMU might still be in guest context.
> In this situation we spin at low priority in real mode waiting for
> hwthread_req to become zero.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> I think this would be best going through the powerpc tree. Alex,
> if you can give me an acked-by for this that would be appreciated.
Acked-by: Alexander Graf <agraf@suse.de>
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Paul Mackerras <paulus@samba.org>, linuxppc-dev@ozlabs.org
Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] powerpc: powernv: Return to cpu offline loop when finished in KVM guest
Date: Wed, 17 Dec 2014 13:40:46 +0100 [thread overview]
Message-ID: <549179CE.7030100@suse.de> (raw)
In-Reply-To: <20141203034840.GA612@iris.ozlabs.ibm.com>
On 03.12.14 04:48, Paul Mackerras wrote:
> When a secondary hardware thread has finished running a KVM guest, we
> currently put that thread into nap mode using a nap instruction in
> the KVM code. This changes the code so that instead of doing a nap
> instruction directly, we instead cause the call to power7_nap() that
> put the thread into nap mode to return. The reason for doing this is
> to avoid having the KVM code having to know what low-power mode to
> put the thread into.
>
> In the case of a secondary thread used to run a KVM guest, the thread
> will be offline from the point of view of the host kernel, and the
> relevant power7_nap() call is the one in pnv_smp_cpu_disable().
> In this case we don't want to clear pending IPIs in the offline loop
> in that function, since that might cause us to miss the wakeup for
> the next time the thread needs to run a guest. To tell whether or
> not to clear the interrupt, we use the SRR1 value returned from
> power7_nap(), and check if it indicates an external interrupt. We
> arrange that the return from power7_nap() when we have finished running
> a guest returns 0, so pending interrupts don't get flushed in that
> case.
>
> Note that it is important a secondary thread that has finished
> executing in the guest, or that didn't have a guest to run, should
> not return to power7_nap's caller while the kvm_hstate.hwthread_req
> flag in the PACA is non-zero, because the return from power7_nap
> will reenable the MMU, and the MMU might still be in guest context.
> In this situation we spin at low priority in real mode waiting for
> hwthread_req to become zero.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> I think this would be best going through the powerpc tree. Alex,
> if you can give me an acked-by for this that would be appreciated.
Acked-by: Alexander Graf <agraf@suse.de>
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Paul Mackerras <paulus@samba.org>, linuxppc-dev@ozlabs.org
Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] powerpc: powernv: Return to cpu offline loop when finished in KVM guest
Date: Wed, 17 Dec 2014 13:40:46 +0100 [thread overview]
Message-ID: <549179CE.7030100@suse.de> (raw)
In-Reply-To: <20141203034840.GA612@iris.ozlabs.ibm.com>
On 03.12.14 04:48, Paul Mackerras wrote:
> When a secondary hardware thread has finished running a KVM guest, we
> currently put that thread into nap mode using a nap instruction in
> the KVM code. This changes the code so that instead of doing a nap
> instruction directly, we instead cause the call to power7_nap() that
> put the thread into nap mode to return. The reason for doing this is
> to avoid having the KVM code having to know what low-power mode to
> put the thread into.
>
> In the case of a secondary thread used to run a KVM guest, the thread
> will be offline from the point of view of the host kernel, and the
> relevant power7_nap() call is the one in pnv_smp_cpu_disable().
> In this case we don't want to clear pending IPIs in the offline loop
> in that function, since that might cause us to miss the wakeup for
> the next time the thread needs to run a guest. To tell whether or
> not to clear the interrupt, we use the SRR1 value returned from
> power7_nap(), and check if it indicates an external interrupt. We
> arrange that the return from power7_nap() when we have finished running
> a guest returns 0, so pending interrupts don't get flushed in that
> case.
>
> Note that it is important a secondary thread that has finished
> executing in the guest, or that didn't have a guest to run, should
> not return to power7_nap's caller while the kvm_hstate.hwthread_req
> flag in the PACA is non-zero, because the return from power7_nap
> will reenable the MMU, and the MMU might still be in guest context.
> In this situation we spin at low priority in real mode waiting for
> hwthread_req to become zero.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> I think this would be best going through the powerpc tree. Alex,
> if you can give me an acked-by for this that would be appreciated.
Acked-by: Alexander Graf <agraf@suse.de>
Alex
next prev parent reply other threads:[~2014-12-17 12:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-03 3:48 [PATCH] powerpc: powernv: Return to cpu offline loop when finished in KVM guest Paul Mackerras
2014-12-03 3:48 ` Paul Mackerras
2014-12-17 12:40 ` Alexander Graf [this message]
2014-12-17 12:40 ` Alexander Graf
2014-12-17 12:40 ` Alexander Graf
2014-12-21 14:13 ` Andreas Schwab
2014-12-21 14:13 ` Andreas Schwab
2014-12-21 22:56 ` Alexander Graf
2014-12-21 22:56 ` Alexander Graf
2014-12-21 22:56 ` Alexander Graf
2014-12-22 2:24 ` Michael Ellerman
2014-12-22 2:24 ` Michael Ellerman
2014-12-22 2:24 ` Michael Ellerman
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=549179CE.7030100@suse.de \
--to=agraf@suse.de \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.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.