From: Alexander Graf <agraf@suse.de>
To: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
Cc: benh@au1.ibm.com, aik@au1.ibm.com, qemu-devel@nongnu.org,
qemu-ppc@nongnu.org, paulus@samba.org
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 4/4] target-ppc: Handle ibm, nmi-register RTAS call
Date: Wed, 05 Nov 2014 12:07:25 +0100 [thread overview]
Message-ID: <545A04ED.6040904@suse.de> (raw)
In-Reply-To: <5459FDF1.6010001@linux.vnet.ibm.com>
On 05.11.14 11:37, Aravinda Prasad wrote:
>
>
> On Wednesday 05 November 2014 02:02 PM, Alexander Graf wrote:
>>
>>
>> On 05.11.14 08:13, 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.
>>>
>>> This patch also handles the cases when multi-processors
>>> experience machine check at or about the same time.
>>> As per PAPR, subsequent processors serialize waiting
>>> for the first processor to issue the ibm,nmi-interlock call.
>>> The second processor retries if the first processor which
>>> received a machine check is still reading the error log
>>> and is yet to issue ibm,nmi-interlock call.
>>>
>>> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
>>> ---
>>> hw/ppc/spapr_hcall.c | 16 +++++++
>>> hw/ppc/spapr_rtas.c | 93 +++++++++++++++++++++++++++++++++++++++
>>> include/hw/ppc/spapr.h | 17 +++++++
>>> pc-bios/spapr-rtas/spapr-rtas.S | 38 ++++++++++++++++
>>> 4 files changed, 163 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
>>> index 8f16160..eceb5e5 100644
>>> --- a/hw/ppc/spapr_hcall.c
>>> +++ b/hw/ppc/spapr_hcall.c
>>> @@ -97,6 +97,9 @@ struct rtas_mc_log {
>>> struct rtas_error_log err_log;
>>> };
>>>
>>> +/* Whether machine check handling is in progress by any CPU */
>>> +bool mc_in_progress;
>>> +
>>> static void do_spr_sync(void *arg)
>>> {
>>> struct SPRSyncState *s = arg;
>>> @@ -678,6 +681,19 @@ static target_ulong h_report_mc_err(PowerPCCPU *cpu, sPAPREnvironment *spapr,
>>> cpu_synchronize_state(CPU(ppc_env_get_cpu(env)));
>>>
>>> /*
>>> + * Only one VCPU can process machine check NMI at a time. Hence
>>> + * set the lock mc_in_progress. Once the VCPU finishes processing
>>> + * NMI, it executes ibm,nmi-interlock and mc_in_progress is unset
>>> + * in ibm,nmi-interlock handler. Meanwhile if other VCPUs encounter
>>> + * NMI we return 0 asking the VCPU to retry h_report_mc_err
>>> + */
>>> + if (mc_in_progress == 1) {
>>
>> Please don't depend on bools being numbers. Use true / false. For if()s,
>> just don't use == at all - it makes it more readable.
>
> ok
>
>>
>>> + return 0;
>>> + }
>>> +
>>> + mc_in_progress = 1;
>>> +
>>> + /*
>>> * 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
>>> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
>>> index 2ec2a8e..71c7662 100644
>>> --- a/hw/ppc/spapr_rtas.c
>>> +++ b/hw/ppc/spapr_rtas.c
>>> @@ -36,6 +36,9 @@
>>>
>>> #include <libfdt.h>
>>>
>>> +#define BRANCH_INST_MASK 0xFC000000
>>> +extern bool mc_in_progress;
>>
>> Please put this into the spapr struct.
>
> ok
>
>>
>>> +
>>> static void rtas_display_character(PowerPCCPU *cpu, sPAPREnvironment *spapr,
>>> uint32_t token, uint32_t nargs,
>>> target_ulong args,
>>> @@ -290,6 +293,90 @@ static void rtas_ibm_os_term(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 ori_inst = 0x60630000;
>>> + uint32_t branch_inst = 0x48000002;
>>> + target_ulong guest_machine_check_addr;
>>> + uint32_t trampoline[TRAMPOLINE_INSTS];
>>> + int total_inst = sizeof(trampoline) / sizeof(uint32_t);
>>
>> ARRAY_SIZE(trampoline), though I don't quite understand why you need a
>> variable that contains the same value as a constant (TRAMPOLINE_INSTS).
>>
>> But since you're moving all of those bits into variable fields on the
>> rtas blob itself as we discussed in the last version, I guess this code
>> will go away anyways ;).
>
> I think we still need this. We need to patch the KVMPPC_H_REPORT_MC_ERR
> number and branch address in the trampoline and also, depending on
> whether the guest running in LE/BE we may need to flip the bits in the
> trampoline before copying it to 0x200 machine check vector.
>
> As rtas-blob is part of the guest memory I do not want to patch these in
> rtas-blob, hence I copy the trampoline from the rtas-blob to an array,
> modify accordingly and then move it to 0x200 machine check vector.
Yes, you will still need the array. But the array should be dynamically
sized based on spapr->rtas_info->fwnmi_size which you extract from the
blob on load.
That way you wouldn't need the "total_inst" variable anymore ;).
>
>>
>>> + PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
>>> +
>>> + /* Store the system reset and machine check address */
>>> + guest_machine_check_addr = rtas_ld(args, 1);
>>
>> Load or Store? I don't find the comment particularly useful either ;).
>
> will reword it or may delete it.
>
>>
>>> +
>>> + /*
>>> + * Read the trampoline instructions from RTAS Blob and patch
>>> + * the KVMPPC_H_REPORT_MC_ERR hcall number and the guest
>>> + * machine check address before copying to 0x200 vector
>>> + */
>>> + cpu_physical_memory_read(spapr->rtas_addr + RTAS_TRAMPOLINE_OFFSET,
>>> + trampoline, sizeof(trampoline));
>>> +
>>> + /* Safety Check */
>>
>> Same for this comment.
>
> we have only 0x100 bytes that can be copied at 0x200. If the trampoline
> size exceeds then the next interrupt vector code is overwritten. Hence a
> safety check during compile time to make sure trampoline is within 0x100
> bytes.
I think the check is fine, the comment is just redundant with
QEMU_BUILD_BUG_ON. Either be more verbose in the comment or remove it
;). But something a la
/* check for failure */
BUG_ON(foo);
is useless redundancy, because everyone already knows that BUG_ON checks
for failure.
The interesting bit is the why. Also, as a general rule of thumb, if you
need a comment explaining the "what" of what you're doing, your function
and/or variable names are probably not well chosen ;). But I don't think
this is a problem here.
Thanks for the patches btw :)
Alex
next prev parent reply other threads:[~2014-11-05 11:07 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 7:12 [Qemu-devel] [PATCH v3 0/4] target-ppc: Add FWNMI support in qemu for powerKVM guests Aravinda Prasad
2014-11-05 7:12 ` [Qemu-devel] [PATCH v3 1/4] target-ppc: Extend rtas-blob Aravinda Prasad
2014-11-05 8:11 ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2014-11-05 8:46 ` Aravinda Prasad
2014-11-05 9:00 ` Alexander Graf
2014-11-05 9:07 ` Alexander Graf
2014-11-05 10:41 ` Aravinda Prasad
2014-11-05 7:12 ` [Qemu-devel] [PATCH v3 2/4] target-ppc: Register and handle HCALL to receive updated RTAS region Aravinda Prasad
2014-11-05 7:12 ` [Qemu-devel] [PATCH v3 3/4] target-ppc: Build error log Aravinda Prasad
2014-11-05 7:13 ` [Qemu-devel] [PATCH v3 4/4] target-ppc: Handle ibm, nmi-register RTAS call Aravinda Prasad
2014-11-05 8:32 ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2014-11-05 10:37 ` Aravinda Prasad
2014-11-05 11:07 ` Alexander Graf [this message]
2014-11-05 11:24 ` Aravinda Prasad
2014-11-05 11:27 ` Alexander Graf
2014-11-05 15:46 ` Tom Musta
2014-11-06 10:00 ` Aravinda Prasad
2014-11-06 10:29 ` Alexander Graf
2014-11-06 10:36 ` Aravinda Prasad
2014-11-11 3:19 ` David Gibson
2014-11-11 5:48 ` Aravinda Prasad
2014-11-11 6:11 ` David Gibson
2014-11-11 6:51 ` Aravinda Prasad
2014-11-11 11:30 ` David Gibson
2014-11-11 3:16 ` [Qemu-devel] " David Gibson
2014-11-11 6:44 ` Aravinda Prasad
2014-11-13 3:52 ` David Gibson
2014-11-13 5:58 ` Aravinda Prasad
2014-11-13 10:32 ` David Gibson
2014-11-13 11:48 ` Aravinda Prasad
2014-11-13 12:44 ` David Gibson
2014-11-13 14:36 ` Aravinda Prasad
2014-11-14 0:42 ` David Gibson
2014-11-14 8:24 ` Aravinda Prasad
2014-11-11 3:24 ` [Qemu-devel] [PATCH v3 0/4] target-ppc: Add FWNMI support in qemu for powerKVM guests David Gibson
2014-11-11 7:15 ` Aravinda Prasad
2014-11-13 3:57 ` David Gibson
2014-11-13 6:10 ` Aravinda Prasad
2014-11-19 5:48 ` Aravinda Prasad
2014-11-19 10:32 ` Alexander Graf
2014-11-19 11:44 ` David Gibson
2014-11-19 12:22 ` Alexander Graf
2014-11-19 12:42 ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2014-11-19 12:57 ` [Qemu-devel] " David Gibson
2015-04-02 4:28 ` [Qemu-devel] [Qemu-ppc] " Alexey Kardashevskiy
2015-04-02 4:46 ` David Gibson
2015-07-02 9:11 ` Alexey Kardashevskiy
2015-07-03 6:01 ` David Gibson
2015-07-08 8:28 ` Aravinda Prasad
2015-08-07 3:37 ` Sam Bobroff
2015-08-09 13:53 ` Alexander Graf
2015-08-10 4:05 ` Sam Bobroff
2015-09-01 11:07 ` Aravinda Prasad
2015-09-02 6:34 ` Sam Bobroff
2015-09-02 10:37 ` Aravinda Prasad
2015-09-02 23:53 ` David Gibson
2015-09-03 3:24 ` Sam Bobroff
2015-09-03 5:05 ` David Gibson
2015-09-03 5:18 ` Paul Mackerras
2015-09-03 6:22 ` Sam Bobroff
2015-09-03 18:30 ` Aravinda Prasad
2015-09-04 5:02 ` David Gibson
2015-09-04 5:01 ` David Gibson
2015-09-03 2:02 ` Paul Mackerras
2015-09-03 17:49 ` Aravinda Prasad
2015-09-01 6:21 ` 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=545A04ED.6040904@suse.de \
--to=agraf@suse.de \
--cc=aik@au1.ibm.com \
--cc=aravinda@linux.vnet.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 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.