From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: Save/Restore CR over vcpu_run
Date: Mon, 05 Mar 2012 22:54:52 +0000 [thread overview]
Message-ID: <4F55443C.1080406@freescale.com> (raw)
In-Reply-To: <1330963334-5717-1-git-send-email-agraf@suse.de>
On 03/05/2012 10:02 AM, Alexander Graf wrote:
> @@ -442,6 +444,7 @@ heavyweight_exit:
>
> /* Return to kvm_vcpu_run(). */
> mtlr r5
> + mtcr r6
> addi r1, r1, HOST_STACK_SIZE
> /* r3 still contains the return code from kvmppc_handle_exit(). */
> blr
> @@ -459,6 +462,9 @@ _GLOBAL(__kvmppc_vcpu_run)
> mflr r3
> PPC_STL r3, HOST_STACK_LR(r1)
>
> + mfcr r5
> + stw r5, HOST_CR(r1)
If you move the mfcr before the PPC_STL they should be able to run in
parallel. Otherwise on e500mc mfcr will wait for PPC_STL to take its 3
cycles and then mfcr will take 5 cyles before the stw of HOST_CR.
Alternatively, consider using mcrf/mtocrf three times.
Similar issues in booke_interrupts.S (except we can't assume mtocrf
exists there), but I'm less worried about that one as it still needs an
optimization pass in general.
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: <kvm-ppc@vger.kernel.org>, <kvm@vger.kernel.org>
Subject: Re: [PATCH] KVM: PPC: Save/Restore CR over vcpu_run
Date: Mon, 5 Mar 2012 16:54:52 -0600 [thread overview]
Message-ID: <4F55443C.1080406@freescale.com> (raw)
In-Reply-To: <1330963334-5717-1-git-send-email-agraf@suse.de>
On 03/05/2012 10:02 AM, Alexander Graf wrote:
> @@ -442,6 +444,7 @@ heavyweight_exit:
>
> /* Return to kvm_vcpu_run(). */
> mtlr r5
> + mtcr r6
> addi r1, r1, HOST_STACK_SIZE
> /* r3 still contains the return code from kvmppc_handle_exit(). */
> blr
> @@ -459,6 +462,9 @@ _GLOBAL(__kvmppc_vcpu_run)
> mflr r3
> PPC_STL r3, HOST_STACK_LR(r1)
>
> + mfcr r5
> + stw r5, HOST_CR(r1)
If you move the mfcr before the PPC_STL they should be able to run in
parallel. Otherwise on e500mc mfcr will wait for PPC_STL to take its 3
cycles and then mfcr will take 5 cyles before the stw of HOST_CR.
Alternatively, consider using mcrf/mtocrf three times.
Similar issues in booke_interrupts.S (except we can't assume mtocrf
exists there), but I'm less worried about that one as it still needs an
optimization pass in general.
-Scott
next prev parent reply other threads:[~2012-03-05 22:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-05 16:02 [PATCH] KVM: PPC: Save/Restore CR over vcpu_run Alexander Graf
2012-03-05 16:02 ` Alexander Graf
2012-03-05 22:54 ` Scott Wood [this message]
2012-03-05 22:54 ` Scott Wood
2012-03-12 19:26 ` Alexander Graf
2012-03-12 19:26 ` Alexander Graf
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=4F55443C.1080406@freescale.com \
--to=scottwood@freescale.com \
--cc=agraf@suse.de \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.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.