From: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
To: Alexander Graf <agraf@suse.de>
Cc: "aik@au1.ibm.com" <aik@au1.ibm.com>,
"benh@au1.ibm.com" <benh@au1.ibm.com>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"paulus@samba.org" <paulus@samba.org>
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 4/5] target-ppc: Handle ibm, nmi-register RTAS call
Date: Thu, 04 Sep 2014 19:19:15 +0530 [thread overview]
Message-ID: <54086DDB.1060800@linux.vnet.ibm.com> (raw)
In-Reply-To: <6AD4C807-F0DD-46F5-ADBC-A91D9D7B15E7@suse.de>
On Thursday 04 September 2014 06:39 PM, Alexander Graf wrote:
>
>
>> Am 04.09.2014 um 10:25 schrieb Aravinda Prasad <aravinda@linux.vnet.ibm.com>:
>>
>>
>>
>>> On Friday 29 August 2014 03:46 AM, Alexander Graf wrote:
>>>
>>>
>>>> On 28.08.14 19:42, Aravinda Prasad wrote:
>>>>
>>>>
>>>>> On Thursday 28 August 2014 02:07 PM, Alexander Graf wrote:
>>>>>
>>>>>
>>>>>> On 28.08.14 08:38, Aravinda Prasad wrote:
>>>>>>
>>>>>>
>>>>>>> On Wednesday 27 August 2014 04:07 PM, Alexander Graf wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 25.08.14 15:45, Aravinda Prasad wrote:
>>>>>>>> This patch adds FWNMI support in qemu for powerKVM
>>>>>>>> guests by handling the ibm,nmi-register rtas call.
>>>>>>>> Whenever OS issues ibm,nmi-register RTAS call, the
>>>>>>>> machine check notification address is saved and the
>>>>>>>> machine check interrupt vector 0x200 is patched to
>>>>>>>> issue a private hcall.
>>>>>>>>
>>>>>>>> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
>>>>>>>> ---
>>>>>>>> hw/ppc/spapr_rtas.c | 91 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>> include/hw/ppc/spapr.h | 8 ++++
>>>>>>>> 2 files changed, 98 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
>>>>>>>> index 02ddbf9..1135d2b 100644
>>>>>>>> --- a/hw/ppc/spapr_rtas.c
>>>>>>>> +++ b/hw/ppc/spapr_rtas.c
>>>>>>>> @@ -277,6 +277,91 @@ static void rtas_ibm_set_system_parameter(PowerPCCPU *cpu,
>>>>>>>> rtas_st(rets, 0, ret);
>>>>>>>> }
>>>>>>>>
>>>>>>>> +static void rtas_ibm_nmi_register(PowerPCCPU *cpu,
>>>>>>>> + sPAPREnvironment *spapr,
>>>>>>>> + uint32_t token, uint32_t nargs,
>>>>>>>> + target_ulong args,
>>>>>>>> + uint32_t nret, target_ulong rets)
>>>>>>>> +{
>>>>>>>> + int i;
>>>>>>>> + uint32_t branch_inst = 0x48000002;
>>>>>>>> + target_ulong guest_machine_check_addr;
>>>>>>>> + PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
>>>>>>>> + /*
>>>>>>>> + * Trampoline saves r3 in sprg2 and issues private hcall
>>>>>>>> + * to request qemu to build error log. QEMU builds the
>>>>>>>> + * error log, copies to rtas-blob and returns the address.
>>>>>>>> + * The initial 16 bytes in rtas-blob consists of saved srr0
>>>>>>>> + * and srr1 which we restore and pass on the actual error
>>>>>>>> + * log address to OS handled mcachine check notification
>>>>>>>> + * routine
>>>>>>>> + */
>>>>>>>> + uint32_t trampoline[] = {
>>>>>>>> + 0x7c7243a6, /* mtspr SPRN_SPRG2,r3 */
>>>>>>>> + 0x38600000, /* li r3,0 */
>>>>>>>> + /* 0xf004 is the KVMPPC_H_REPORT_ERR private HCALL */
>>>>>>>> + 0x6063f004, /* ori r3,r3,f004 */
>>>>>>>> + /* Issue H_CALL */
>>>>>>>> + 0x44000022, /* sc 1 */
>>>>>>>
>>>>>>> So up to here we're saving r3 in SPRG2 (how do we know that we can
>>>>>>> clobber it?) and call our special hypercall.
>>>>>>>
>>>>>>> But what does all the cruft below here do?
>>>>>>
>>>>>> The saved r3 in SPRG2 is consumed in KVMPPC_H_REPORT_ERR hcall, hence we
>>>>>> can clobber SPRG2 after hcall returns. I have included a comment in
>>>>>> patch 3/5 while building error log. I think better I add one here as well.
>>>>>>
>>>>>>>
>>>>>>>> + 0x7c9243a6, /* mtspr r4 sprg2 */
>>>>>>>
>>>>>>> Apart from th fact that your order is wrong, this destroys the value of
>>>>>>> r3 that we saved above again.
>>>>>>
>>>>>> SPRG2 is saved inside hcall and hence we don't need SPRG2 further after
>>>>>> KVMPPC_H_REPORT_ERR hcall returns.
>>>>>>
>>>>>>>
>>>>>>>> + 0xe8830000, /* ld r4, 0(r3) */
>>>>>>>> + 0x7c9a03a6, /* mtspr r4, srr0 */
>>>>>>>> + 0xe8830008, /* ld r4, 8(r3) */
>>>>>>>> + 0x7c9b03a6, /* mtspr r4, srr1 */
>>>>>>>
>>>>>>> Can't we just set srr0 and srr1 directly?
>>>>>>
>>>>>> I checked for instructions in ISA which set srr0/1 directly given an
>>>>>> address, but could not find any such instructions.
>>>>>
>>>>> I mean from QEMU :).
>>>>
>>>> srr0 and srr1, which are properly set when 0x200 is invoked, are
>>>> clobbered when we return from KVMPPC_H_REPORT_ERR hcall. I think they
>>>> are modified before issuing rfid (I can see them getting clobbered from
>>>> QEMU monitor). However when we jump to OS registered machine check
>>>> routine srr0 and srr1 should reflect the value they had when 0x200 was
>>>> invoked.
>>>>
>>>> Hence srr0 and srr1 are saved in hcall and restored when we return from
>>>> hcall. Also we don't have enough scratch registers available to save
>>>> these before invoking hcall from 0x200.
>>>>
>>>> Or am I missing other ways to do this from QEMU?
>>>
>>> If you just do
>>>
>>> cpu_synchronize_state() and then change env->spr[SPRN_SRR0/1] inside
>>> your hypercall handler that should also change the value when you return
>>> from the hcall.
>>
>> I tried cpu_synchronize_state(), however, srr0 and srr1 are still clobbered.
>>
>> Just before I issue hcall from 0x200 I see the following values from
>> QEMU monitor:
>>
>> SRR0 d000000000f40264 SRR1 8000000000209033
>>
>> Inside hcall, I call cpu_synchronize_state(). As soon as I return from
>> hcall I see:
>>
>> SRR0 0000000000000214 SRR1 8000000000001001
>>
>> I see SRR0 is now set to nip in 0x200 and SRR1 to msr value. I think it
>> is reset during returning from hcall before executing rfid.
>>
>> So I think I still need to explicitly save/restore srr0 and srr1 across
>> hcall.
>
> Please paste the diff that you did to enable use of cpu_synchronize_state().
@@ -668,20 +668,22 @@ static target_ulong h_rtas_update(PowerP
return 0;
}
static target_ulong h_report_mc_err(PowerPCCPU *cpu, sPAPREnvironment
*spapr,
target_ulong opcode, target_ulong *args)
{
struct rtas_mc_log mc_log;
CPUPPCState *env = &cpu->env;
PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+ cpu_synchronize_state(CPU(ppc_env_get_cpu(env)));
+
/*
* We save the original r3 register in SPRG2 in 0x200 vector,
* which is patched during call to ibm.nmi-register. Original
* r3 is required to be included in error log
*/
mc_log.r3 = env->spr[SPR_SPRG2];
/*
* SRR0 and SRR1, containing nip and msr at the time of exception,
* are clobbered when we return from this hcall. Hence they
>
> Alex
>
>>
>>>
>>>
>>> Alex
>>
>> --
>> Regards,
>> Aravinda
>>
>
--
Regards,
Aravinda
next prev parent reply other threads:[~2014-09-04 13:49 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-25 13:45 [Qemu-devel] [PATCH 0/5] target-ppc: Add FWNMI support in QEMU for powerKVM guests Aravinda Prasad
2014-08-25 13:45 ` [Qemu-devel] [PATCH 1/5] target-ppc: Extend rtas-blob Aravinda Prasad
2014-08-26 5:38 ` David Gibson
2014-08-26 6:34 ` Aravinda Prasad
2014-08-26 7:24 ` David Gibson
2014-08-28 10:40 ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2014-08-28 18:20 ` Aravinda Prasad
2014-08-28 22:18 ` Alexander Graf
2014-08-28 22:25 ` Benjamin Herrenschmidt
2014-08-29 0:40 ` Alexander Graf
2014-08-29 1:06 ` Benjamin Herrenschmidt
2014-08-29 1:33 ` Alexander Graf
2014-08-29 2:42 ` Benjamin Herrenschmidt
2014-08-29 3:46 ` David Gibson
2014-08-29 3:47 ` David Gibson
2014-09-01 7:46 ` [Qemu-devel] " Alexey Kardashevskiy
2014-09-01 11:23 ` Aravinda Prasad
2014-09-02 4:09 ` Alexey Kardashevskiy
2014-09-02 5:25 ` Aravinda Prasad
2014-09-02 5:49 ` Alexey Kardashevskiy
2014-09-02 5:56 ` Aravinda Prasad
2014-09-02 6:34 ` Alexey Kardashevskiy
2014-09-02 7:07 ` Aravinda Prasad
2014-09-02 8:40 ` Alexey Kardashevskiy
2014-09-02 9:30 ` Aravinda Prasad
2014-09-02 13:17 ` Alexey Kardashevskiy
2014-08-25 13:45 ` [Qemu-devel] [PATCH 2/5] target-ppc: Register and handle HCALL to receive updated RTAS region Aravinda Prasad
2014-08-26 5:39 ` David Gibson
2014-08-26 6:15 ` Benjamin Herrenschmidt
2014-08-26 7:24 ` David Gibson
2014-08-26 20:05 ` Benjamin Herrenschmidt
2014-08-25 13:45 ` [Qemu-devel] [PATCH 3/5] target-ppc: Build error log Aravinda Prasad
2014-08-26 5:47 ` David Gibson
2014-08-26 6:40 ` Aravinda Prasad
2014-08-27 9:50 ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2014-08-28 6:12 ` Aravinda Prasad
2014-08-28 8:36 ` Alexander Graf
2014-08-28 10:21 ` Benjamin Herrenschmidt
2014-08-28 10:29 ` Alexander Graf
2014-08-28 10:33 ` Benjamin Herrenschmidt
2014-08-28 10:34 ` Benjamin Herrenschmidt
2014-08-28 17:17 ` Aravinda Prasad
2014-08-28 20:07 ` Benjamin Herrenschmidt
2014-08-30 8:06 ` Aravinda Prasad
2014-08-25 13:45 ` [Qemu-devel] [PATCH 4/5] target-ppc: Handle ibm, nmi-register RTAS call Aravinda Prasad
2014-08-26 6:02 ` David Gibson
2014-08-26 6:57 ` Aravinda Prasad
2014-08-27 10:37 ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2014-08-28 6:38 ` Aravinda Prasad
2014-08-28 8:37 ` Alexander Graf
2014-08-28 13:06 ` Tom Musta
2014-08-28 13:11 ` Alexander Graf
2014-08-28 17:42 ` Aravinda Prasad
2014-08-28 22:16 ` Alexander Graf
2014-08-30 8:08 ` Aravinda Prasad
2014-09-04 8:25 ` Aravinda Prasad
2014-09-04 13:09 ` Alexander Graf
2014-09-04 13:49 ` Aravinda Prasad [this message]
2014-09-05 8:46 ` Alexander Graf
2014-09-05 8:52 ` Aravinda Prasad
2014-09-07 20:47 ` Alexander Graf
2014-09-26 3:58 ` Alexey Kardashevskiy
2014-10-06 6:32 ` Aravinda Prasad
2014-10-06 9:40 ` Alexander Graf
2014-10-06 11:01 ` Aravinda Prasad
2014-08-25 13:45 ` [Qemu-devel] [PATCH 5/5] target-ppc: Handle cases when multi-processors get machine-check Aravinda Prasad
2014-08-26 6:04 ` David Gibson
2014-08-26 7:04 ` Aravinda Prasad
2014-08-27 10:40 ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2014-08-28 6:56 ` Aravinda Prasad
2014-08-28 8:39 ` Alexander Graf
2014-08-28 8:42 ` Alexander Graf
2014-08-28 17:45 ` Aravinda Prasad
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=54086DDB.1060800@linux.vnet.ibm.com \
--to=aravinda@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=aik@au1.ibm.com \
--cc=benh@au1.ibm.com \
--cc=paulus@samba.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.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 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).