qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
To: Alexander Graf <agraf@suse.de>
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 16:54:40 +0530	[thread overview]
Message-ID: <545A08F8.3080802@linux.vnet.ibm.com> (raw)
In-Reply-To: <545A04ED.6040904@suse.de>



On Wednesday 05 November 2014 04:37 PM, Alexander Graf wrote:
> 
> 
> 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 ;).

Yes, I will fix it that way.

> 
>>
>>>
>>>> +    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

I will add above lines as comment.

> ;). 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
> 

-- 
Regards,
Aravinda

  reply	other threads:[~2014-11-05 11:25 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
2014-11-05 11:24         ` Aravinda Prasad [this message]
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=545A08F8.3080802@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).