diff mbox

[v3,1/5] ppc: spapr: Register and handle HCALL to receive updated RTAS region

Message ID 150287473305.9760.9007559736340136424.stgit@aravinda
State New
Headers show

Commit Message

Aravinda Prasad Aug. 16, 2017, 9:12 a.m. UTC 
Receive updates from SLOF about the updated rtas-base.
A separate patch for SLOF [1] adds functionality to invoke
a private HCALL whenever OS issues instantiate-rtas with
a new rtas-base.

This is required as QEMU needs to know the updated rtas-base
as it allocates error reporting structure in RTAS space upon
a machine check exception.

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html

Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/ppc/spapr_hcall.c   |    8 ++++++++
 include/hw/ppc/spapr.h |    4 +++-
 2 files changed, 11 insertions(+), 1 deletion(-)

Comments

David Gibson Aug. 17, 2017, 1:34 a.m. UTC | #1 
On Wed, Aug 16, 2017 at 02:42:13PM +0530, Aravinda Prasad wrote:
> Receive updates from SLOF about the updated rtas-base.
> A separate patch for SLOF [1] adds functionality to invoke
> a private HCALL whenever OS issues instantiate-rtas with
> a new rtas-base.
> 
> This is required as QEMU needs to know the updated rtas-base
> as it allocates error reporting structure in RTAS space upon
> a machine check exception.
> 
> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html
> 
> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

Actually, I take back this R-b, see below.

In any case I'm not willing to apply the patches which depend on this
until the corresponding SLOF update is merged as well.

> ---
>  hw/ppc/spapr_hcall.c   |    8 ++++++++
>  include/hw/ppc/spapr.h |    4 +++-
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 72ea5a8..e66c72e 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1062,6 +1062,13 @@ static target_ulong h_rtas(PowerPCCPU *cpu, sPAPRMachineState *spapr,
>                             nret, rtas_r3 + 12 + 4*nargs);
>  }
>  
> +static target_ulong h_rtas_update(PowerPCCPU *cpu, sPAPRMachineState *spapr,
> +                                  target_ulong opcode, target_ulong *args)
> +{
> +    spapr->rtas_addr = args[0];
> +    return 0;
> +}
> +
>  static target_ulong h_logical_load(PowerPCCPU *cpu, sPAPRMachineState *spapr,
>                                     target_ulong opcode, target_ulong *args)
>  {
> @@ -1717,6 +1724,7 @@ static void hypercall_register_types(void)
>  
>      /* qemu/KVM-PPC specific hcalls */
>      spapr_register_hypercall(KVMPPC_H_RTAS, h_rtas);
> +    spapr_register_hypercall(KVMPPC_H_RTAS_UPDATE, h_rtas_update);
>  
>      /* ibm,client-architecture-support support */
>      spapr_register_hypercall(KVMPPC_H_CAS, h_client_architecture_support);
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index 2a303a7..46012b3 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -90,6 +90,7 @@ struct sPAPRMachineState {
>  
>      hwaddr rma_size;
>      int vrma_adjust;
> +    hwaddr rtas_addr;

This can now change at runtime, which means it needs to be migrated -
that's not happening in your patches yet.

>      ssize_t rtas_size;
>      void *rtas_blob;
>      long kernel_size;
> @@ -399,7 +400,8 @@ struct sPAPRMachineState {
>  #define KVMPPC_H_LOGICAL_MEMOP  (KVMPPC_HCALL_BASE + 0x1)
>  /* Client Architecture support */
>  #define KVMPPC_H_CAS            (KVMPPC_HCALL_BASE + 0x2)
> -#define KVMPPC_HCALL_MAX        KVMPPC_H_CAS
> +#define KVMPPC_H_RTAS_UPDATE    (KVMPPC_HCALL_BASE + 0x3)
> +#define KVMPPC_HCALL_MAX        KVMPPC_H_RTAS_UPDATE
>  
>  typedef struct sPAPRDeviceTreeUpdateHeader {
>      uint32_t version_id;
>
Nikunj A Dadhania Aug. 17, 2017, 10:27 a.m. UTC | #2 
David Gibson <david@gibson.dropbear.id.au> writes:

> On Wed, Aug 16, 2017 at 02:42:13PM +0530, Aravinda Prasad wrote:
>> Receive updates from SLOF about the updated rtas-base.
>> A separate patch for SLOF [1] adds functionality to invoke
>> a private HCALL whenever OS issues instantiate-rtas with
>> a new rtas-base.
>> 
>> This is required as QEMU needs to know the updated rtas-base
>> as it allocates error reporting structure in RTAS space upon
>> a machine check exception.
>> 
>> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html
>> 
>> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
>> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
>
> Actually, I take back this R-b, see below.
>
> In any case I'm not willing to apply the patches which depend on this
> until the corresponding SLOF update is merged as well.

We already have this sitting around in SLOF for a while

https://git.qemu.org/gitweb.cgi?p=SLOF.git;a=commit;f=lib/libhvcall/libhvcall.h;h=f9a60de30492863811c2cdf6f28988c9e8a2c3d9

Regards
Nikunj
Aravinda Prasad Aug. 21, 2017, 9:42 a.m. UTC | #3 
On Thursday 17 August 2017 07:04 AM, David Gibson wrote:
> On Wed, Aug 16, 2017 at 02:42:13PM +0530, Aravinda Prasad wrote:
>> Receive updates from SLOF about the updated rtas-base.
>> A separate patch for SLOF [1] adds functionality to invoke
>> a private HCALL whenever OS issues instantiate-rtas with
>> a new rtas-base.
>>
>> This is required as QEMU needs to know the updated rtas-base
>> as it allocates error reporting structure in RTAS space upon
>> a machine check exception.
>>
>> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html
>>
>> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
>> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> 
> Actually, I take back this R-b, see below.
> 
> In any case I'm not willing to apply the patches which depend on this
> until the corresponding SLOF update is merged as well.

As Nikunj mentioned, SLOF updates are already merged.

> 
>> ---
>>  hw/ppc/spapr_hcall.c   |    8 ++++++++
>>  include/hw/ppc/spapr.h |    4 +++-
>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
>> index 72ea5a8..e66c72e 100644
>> --- a/hw/ppc/spapr_hcall.c
>> +++ b/hw/ppc/spapr_hcall.c
>> @@ -1062,6 +1062,13 @@ static target_ulong h_rtas(PowerPCCPU *cpu, sPAPRMachineState *spapr,
>>                             nret, rtas_r3 + 12 + 4*nargs);
>>  }
>>  
>> +static target_ulong h_rtas_update(PowerPCCPU *cpu, sPAPRMachineState *spapr,
>> +                                  target_ulong opcode, target_ulong *args)
>> +{
>> +    spapr->rtas_addr = args[0];
>> +    return 0;
>> +}
>> +
>>  static target_ulong h_logical_load(PowerPCCPU *cpu, sPAPRMachineState *spapr,
>>                                     target_ulong opcode, target_ulong *args)
>>  {
>> @@ -1717,6 +1724,7 @@ static void hypercall_register_types(void)
>>  
>>      /* qemu/KVM-PPC specific hcalls */
>>      spapr_register_hypercall(KVMPPC_H_RTAS, h_rtas);
>> +    spapr_register_hypercall(KVMPPC_H_RTAS_UPDATE, h_rtas_update);
>>  
>>      /* ibm,client-architecture-support support */
>>      spapr_register_hypercall(KVMPPC_H_CAS, h_client_architecture_support);
>> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
>> index 2a303a7..46012b3 100644
>> --- a/include/hw/ppc/spapr.h
>> +++ b/include/hw/ppc/spapr.h
>> @@ -90,6 +90,7 @@ struct sPAPRMachineState {
>>  
>>      hwaddr rma_size;
>>      int vrma_adjust;
>> +    hwaddr rtas_addr;
> 
> This can now change at runtime, which means it needs to be migrated -
> that's not happening in your patches yet.

Yes. Need a bit of help in understanding the migration process.

As rtas_addr is updated by SLOF, I think we need to modify SLOF to issue
KVMPPC_H_RTAS_UPDATE HCALL with the new rtas_addr during migration. But
I am not sure if SLOF is notified of migrations.

Regards,
Aravinda

> 
>>      ssize_t rtas_size;
>>      void *rtas_blob;
>>      long kernel_size;
>> @@ -399,7 +400,8 @@ struct sPAPRMachineState {
>>  #define KVMPPC_H_LOGICAL_MEMOP  (KVMPPC_HCALL_BASE + 0x1)
>>  /* Client Architecture support */
>>  #define KVMPPC_H_CAS            (KVMPPC_HCALL_BASE + 0x2)
>> -#define KVMPPC_HCALL_MAX        KVMPPC_H_CAS
>> +#define KVMPPC_H_RTAS_UPDATE    (KVMPPC_HCALL_BASE + 0x3)
>> +#define KVMPPC_HCALL_MAX        KVMPPC_H_RTAS_UPDATE
>>  
>>  typedef struct sPAPRDeviceTreeUpdateHeader {
>>      uint32_t version_id;
>>
>
David Gibson Aug. 22, 2017, 3:33 a.m. UTC | #4 
On Mon, Aug 21, 2017 at 03:12:49PM +0530, Aravinda Prasad wrote:
> 
> 
> On Thursday 17 August 2017 07:04 AM, David Gibson wrote:
> > On Wed, Aug 16, 2017 at 02:42:13PM +0530, Aravinda Prasad wrote:
> >> Receive updates from SLOF about the updated rtas-base.
> >> A separate patch for SLOF [1] adds functionality to invoke
> >> a private HCALL whenever OS issues instantiate-rtas with
> >> a new rtas-base.
> >>
> >> This is required as QEMU needs to know the updated rtas-base
> >> as it allocates error reporting structure in RTAS space upon
> >> a machine check exception.
> >>
> >> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html
> >>
> >> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
> >> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> > 
> > Actually, I take back this R-b, see below.
> > 
> > In any case I'm not willing to apply the patches which depend on this
> > until the corresponding SLOF update is merged as well.
> 
> As Nikunj mentioned, SLOF updates are already merged.

In qemu as well as SLOF master, ok, good.  Commit message could do
with updating to reflect that.

> >>  hw/ppc/spapr_hcall.c   |    8 ++++++++
> >>  include/hw/ppc/spapr.h |    4 +++-
> >>  2 files changed, 11 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> >> index 72ea5a8..e66c72e 100644
> >> --- a/hw/ppc/spapr_hcall.c
> >> +++ b/hw/ppc/spapr_hcall.c
> >> @@ -1062,6 +1062,13 @@ static target_ulong h_rtas(PowerPCCPU *cpu, sPAPRMachineState *spapr,
> >>                             nret, rtas_r3 + 12 + 4*nargs);
> >>  }
> >>  
> >> +static target_ulong h_rtas_update(PowerPCCPU *cpu, sPAPRMachineState *spapr,
> >> +                                  target_ulong opcode, target_ulong *args)
> >> +{
> >> +    spapr->rtas_addr = args[0];
> >> +    return 0;
> >> +}
> >> +
> >>  static target_ulong h_logical_load(PowerPCCPU *cpu, sPAPRMachineState *spapr,
> >>                                     target_ulong opcode, target_ulong *args)
> >>  {
> >> @@ -1717,6 +1724,7 @@ static void hypercall_register_types(void)
> >>  
> >>      /* qemu/KVM-PPC specific hcalls */
> >>      spapr_register_hypercall(KVMPPC_H_RTAS, h_rtas);
> >> +    spapr_register_hypercall(KVMPPC_H_RTAS_UPDATE, h_rtas_update);
> >>  
> >>      /* ibm,client-architecture-support support */
> >>      spapr_register_hypercall(KVMPPC_H_CAS, h_client_architecture_support);
> >> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> >> index 2a303a7..46012b3 100644
> >> --- a/include/hw/ppc/spapr.h
> >> +++ b/include/hw/ppc/spapr.h
> >> @@ -90,6 +90,7 @@ struct sPAPRMachineState {
> >>  
> >>      hwaddr rma_size;
> >>      int vrma_adjust;
> >> +    hwaddr rtas_addr;
> > 
> > This can now change at runtime, which means it needs to be migrated -
> > that's not happening in your patches yet.
> 
> Yes. Need a bit of help in understanding the migration process.
> 
> As rtas_addr is updated by SLOF, I think we need to modify SLOF to issue
> KVMPPC_H_RTAS_UPDATE HCALL with the new rtas_addr during migration. But
> I am not sure if SLOF is notified of migrations.

Uh.. no.  By the time you're migrating chances are SLOF isn't even
running any more, and it wouldn't make sense for it to be aware of
migration anyway.

Instead we need to add the rtas_addr field to the vmstate information
for the spapr machine object.  However, we can't just add it plain,
because that would break backwards migration.  Instead we'll need to
add another sub-vmstate which will migrate rtas_addr if it differs
from the default value.
Aravinda Prasad Aug. 22, 2017, 7:16 a.m. UTC | #5 
On Tuesday 22 August 2017 09:03 AM, David Gibson wrote:
> On Mon, Aug 21, 2017 at 03:12:49PM +0530, Aravinda Prasad wrote:
>>
>>
>> On Thursday 17 August 2017 07:04 AM, David Gibson wrote:
>>> On Wed, Aug 16, 2017 at 02:42:13PM +0530, Aravinda Prasad wrote:
>>>> Receive updates from SLOF about the updated rtas-base.
>>>> A separate patch for SLOF [1] adds functionality to invoke
>>>> a private HCALL whenever OS issues instantiate-rtas with
>>>> a new rtas-base.
>>>>
>>>> This is required as QEMU needs to know the updated rtas-base
>>>> as it allocates error reporting structure in RTAS space upon
>>>> a machine check exception.
>>>>
>>>> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html
>>>>
>>>> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
>>>> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
>>>
>>> Actually, I take back this R-b, see below.
>>>
>>> In any case I'm not willing to apply the patches which depend on this
>>> until the corresponding SLOF update is merged as well.
>>
>> As Nikunj mentioned, SLOF updates are already merged.
> 
> In qemu as well as SLOF master, ok, good.  Commit message could do
> with updating to reflect that.

Will update.

> 
>>>>  hw/ppc/spapr_hcall.c   |    8 ++++++++
>>>>  include/hw/ppc/spapr.h |    4 +++-
>>>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
>>>> index 72ea5a8..e66c72e 100644
>>>> --- a/hw/ppc/spapr_hcall.c
>>>> +++ b/hw/ppc/spapr_hcall.c
>>>> @@ -1062,6 +1062,13 @@ static target_ulong h_rtas(PowerPCCPU *cpu, sPAPRMachineState *spapr,
>>>>                             nret, rtas_r3 + 12 + 4*nargs);
>>>>  }
>>>>  
>>>> +static target_ulong h_rtas_update(PowerPCCPU *cpu, sPAPRMachineState *spapr,
>>>> +                                  target_ulong opcode, target_ulong *args)
>>>> +{
>>>> +    spapr->rtas_addr = args[0];
>>>> +    return 0;
>>>> +}
>>>> +
>>>>  static target_ulong h_logical_load(PowerPCCPU *cpu, sPAPRMachineState *spapr,
>>>>                                     target_ulong opcode, target_ulong *args)
>>>>  {
>>>> @@ -1717,6 +1724,7 @@ static void hypercall_register_types(void)
>>>>  
>>>>      /* qemu/KVM-PPC specific hcalls */
>>>>      spapr_register_hypercall(KVMPPC_H_RTAS, h_rtas);
>>>> +    spapr_register_hypercall(KVMPPC_H_RTAS_UPDATE, h_rtas_update);
>>>>  
>>>>      /* ibm,client-architecture-support support */
>>>>      spapr_register_hypercall(KVMPPC_H_CAS, h_client_architecture_support);
>>>> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
>>>> index 2a303a7..46012b3 100644
>>>> --- a/include/hw/ppc/spapr.h
>>>> +++ b/include/hw/ppc/spapr.h
>>>> @@ -90,6 +90,7 @@ struct sPAPRMachineState {
>>>>  
>>>>      hwaddr rma_size;
>>>>      int vrma_adjust;
>>>> +    hwaddr rtas_addr;
>>>
>>> This can now change at runtime, which means it needs to be migrated -
>>> that's not happening in your patches yet.
>>
>> Yes. Need a bit of help in understanding the migration process.
>>
>> As rtas_addr is updated by SLOF, I think we need to modify SLOF to issue
>> KVMPPC_H_RTAS_UPDATE HCALL with the new rtas_addr during migration. But
>> I am not sure if SLOF is notified of migrations.
> 
> Uh.. no.  By the time you're migrating chances are SLOF isn't even
> running any more, and it wouldn't make sense for it to be aware of
> migration anyway.
> 
> Instead we need to add the rtas_addr field to the vmstate information
> for the spapr machine object.  However, we can't just add it plain,
> because that would break backwards migration.  Instead we'll need to
> add another sub-vmstate which will migrate rtas_addr if it differs
> from the default value.
> 

ok.
diff mbox

Patch

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 72ea5a8..e66c72e 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1062,6 +1062,13 @@  static target_ulong h_rtas(PowerPCCPU *cpu, sPAPRMachineState *spapr,
                            nret, rtas_r3 + 12 + 4*nargs);
 }
 
+static target_ulong h_rtas_update(PowerPCCPU *cpu, sPAPRMachineState *spapr,
+                                  target_ulong opcode, target_ulong *args)
+{
+    spapr->rtas_addr = args[0];
+    return 0;
+}
+
 static target_ulong h_logical_load(PowerPCCPU *cpu, sPAPRMachineState *spapr,
                                    target_ulong opcode, target_ulong *args)
 {
@@ -1717,6 +1724,7 @@  static void hypercall_register_types(void)
 
     /* qemu/KVM-PPC specific hcalls */
     spapr_register_hypercall(KVMPPC_H_RTAS, h_rtas);
+    spapr_register_hypercall(KVMPPC_H_RTAS_UPDATE, h_rtas_update);
 
     /* ibm,client-architecture-support support */
     spapr_register_hypercall(KVMPPC_H_CAS, h_client_architecture_support);
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 2a303a7..46012b3 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -90,6 +90,7 @@  struct sPAPRMachineState {
 
     hwaddr rma_size;
     int vrma_adjust;
+    hwaddr rtas_addr;
     ssize_t rtas_size;
     void *rtas_blob;
     long kernel_size;
@@ -399,7 +400,8 @@  struct sPAPRMachineState {
 #define KVMPPC_H_LOGICAL_MEMOP  (KVMPPC_HCALL_BASE + 0x1)
 /* Client Architecture support */
 #define KVMPPC_H_CAS            (KVMPPC_HCALL_BASE + 0x2)
-#define KVMPPC_HCALL_MAX        KVMPPC_H_CAS
+#define KVMPPC_H_RTAS_UPDATE    (KVMPPC_HCALL_BASE + 0x3)
+#define KVMPPC_HCALL_MAX        KVMPPC_H_RTAS_UPDATE
 
 typedef struct sPAPRDeviceTreeUpdateHeader {
     uint32_t version_id;