From: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
To: Alexander Graf <agraf@suse.de>
Cc: Thomas Huth <thuth@redhat.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] powerpc: Fix definition of SIAR register
Date: Mon, 25 Apr 2016 16:45:56 +0530 [thread overview]
Message-ID: <571DFC6C.6010600@linux.vnet.ibm.com> (raw)
In-Reply-To: <182287E9-40B9-4774-A932-08A0AA499AE3@suse.de>
On Monday 25 April 2016 01:45 PM, Alexander Graf wrote:
>
>> Am 25.04.2016 um 10:08 schrieb Madhavan Srinivasan <maddy@linux.vnet.ibm.com>:
>>
>>
>>
>>> On Friday 08 April 2016 09:24 PM, Thomas Huth wrote:
>>> The SIAR register is available twice, one time as SPR 780 (unprivileged,
>>> but read-only), and one time as SPR 796 (privileged, but read and write).
>>> The Linux kernel code currently uses SPR 780 - and while this is OK for
>>> reading, writing to that register of course does not work.
>>> Since the KVM code tries to write to this register, too (see the mtspr
>>> in book3s_hv_rmhandlers.S), the contents of this register sometimes get
>>> lost for the guests, e.g. during migration of a VM.
>>> To fix this issue, simply switch to the other SPR numer 796 instead.
>> IIUC, SIAR and SDAR are updated by hardware when we take
>> a pmu exception with sampling mode enabled (based on instr).
>> And these register contents are mainly for OS consumption.
>> So, we dont need to restore these register values at all,
>> kindly correct me if I missing something here.
> What if you migrate between a pmu event firing and the os reading siar? Or what if the host gets pmu events? Or we migrate the guest to a different pcpu? In all those cases we need to ensure the register contents are consistent.
Ok got it. Let me try perf record with sample_addr type.
Maddy
>
>> Maddy
>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>> Note: The perf code in core-book3s.c also seems to write to the SIAR
>>> SPR, so that might be affected by this issue, too - but I did
>>> not test the perf code, so I'm not sure about that part.
> Please write a small unit test that fires off pmu events constantly and checks whtether they arrive correctly. Run perf in parallel on the host to increase the chance for breakage.
>
>>> arch/powerpc/include/asm/reg.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
>>> index f5f4c66..6630420 100644
>>> --- a/arch/powerpc/include/asm/reg.h
>>> +++ b/arch/powerpc/include/asm/reg.h
>>> @@ -752,13 +752,13 @@
>>> #define SPRN_PMC6 792
>>> #define SPRN_PMC7 793
>>> #define SPRN_PMC8 794
>>> -#define SPRN_SIAR 780
>>> #define SPRN_SDAR 781
>>> #define SPRN_SIER 784
>>> #define SIER_SIPR 0x2000000 /* Sampled MSR_PR */
>>> #define SIER_SIHV 0x1000000 /* Sampled MSR_HV */
>>> #define SIER_SIAR_VALID 0x0400000 /* SIAR contents valid */
>>> #define SIER_SDAR_VALID 0x0200000 /* SDAR contents valid */
>>> +#define SPRN_SIAR 796
> I'm sure there's a reason (iSeries?) we used the r/o version before. Better introduce a new constant that gives us rw access and use that in the kvm entry/exit code.
>
> Alex
>
>>> #define SPRN_TACR 888
>>> #define SPRN_TCSCR 889
>>> #define SPRN_CSIGR 890
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-04-25 11:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-08 15:54 [PATCH] powerpc: Fix definition of SIAR register Thomas Huth
2016-04-25 6:50 ` Thomas Huth
2016-04-25 8:08 ` Madhavan Srinivasan
2016-04-25 8:15 ` Alexander Graf
2016-04-25 9:16 ` Thomas Huth
2016-04-25 9:31 ` Alexander Graf
2016-04-25 11:15 ` Madhavan Srinivasan [this message]
2016-05-12 4:57 ` Paul Mackerras
2016-05-12 7:27 ` Thomas Huth
2016-05-12 10:40 ` Paul Mackerras
2016-05-12 4:51 ` Paul Mackerras
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=571DFC6C.6010600@linux.vnet.ibm.com \
--to=maddy@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=kvm-ppc@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=thuth@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;
as well as URLs for NNTP newsgroup(s).