Receive updates from SLOF about the updated rtas-base.
A separate patch for SLOF [1] (commit f9a60de3) 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.c | 11 +++++++++++
hw/ppc/spapr_hcall.c | 8 ++++++++
include/hw/ppc/spapr.h | 4 +++-
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index ff87f15..5deae30 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1675,6 +1675,16 @@ static const VMStateDescription vmstate_spapr_patb_entry = {
},
};
+static const VMStateDescription vmstate_spapr_rtas_addr = {
+ .name = "spapr_rtas_addr",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_UINT64(rtas_addr, sPAPRMachineState),
+ VMSTATE_END_OF_LIST()
+ },
+};
+
static const VMStateDescription vmstate_spapr = {
.name = "spapr",
.version_id = 3,
@@ -1694,6 +1704,7 @@ static const VMStateDescription vmstate_spapr = {
&vmstate_spapr_ov5_cas,
&vmstate_spapr_patb_entry,
&vmstate_spapr_pending_events,
+ &vmstate_spapr_rtas_addr,
NULL
}
};
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 8d72bb7..c15a93c 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1088,6 +1088,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)
{
@@ -1750,6 +1757,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 c1b365f..b395aa7 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;
@@ -400,7 +401,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;
On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:
> Receive updates from SLOF about the updated rtas-base.
> A separate patch for SLOF [1] (commit f9a60de3) 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>
Ao I acked this earlier, but I've now realized there might be some
connection between this and discussions taking place elsewhere about
qemu not knowing what SLOF does with the device tree.
At what point will SLOF call the UPDATE_RTAS hcall? I'm guessing at
the time of instantiate-rtas, is that right?
Does SLOF put the RTAS blob address in its internal device tree, or
does it only pass it to the guest via the return parameters from
instantiate-rtas?
> ---
> hw/ppc/spapr.c | 11 +++++++++++
> hw/ppc/spapr_hcall.c | 8 ++++++++
> include/hw/ppc/spapr.h | 4 +++-
> 3 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index ff87f15..5deae30 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1675,6 +1675,16 @@ static const VMStateDescription vmstate_spapr_patb_entry = {
> },
> };
>
> +static const VMStateDescription vmstate_spapr_rtas_addr = {
> + .name = "spapr_rtas_addr",
> + .version_id = 1,
> + .minimum_version_id = 1,
> + .fields = (VMStateField[]) {
> + VMSTATE_UINT64(rtas_addr, sPAPRMachineState),
> + VMSTATE_END_OF_LIST()
> + },
> +};
> +
> static const VMStateDescription vmstate_spapr = {
> .name = "spapr",
> .version_id = 3,
> @@ -1694,6 +1704,7 @@ static const VMStateDescription vmstate_spapr = {
> &vmstate_spapr_ov5_cas,
> &vmstate_spapr_patb_entry,
> &vmstate_spapr_pending_events,
> + &vmstate_spapr_rtas_addr,
> NULL
> }
> };
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 8d72bb7..c15a93c 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1088,6 +1088,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)
> {
> @@ -1750,6 +1757,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 c1b365f..b395aa7 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;
> @@ -400,7 +401,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 | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
David Gibson <david@gibson.dropbear.id.au> writes:
> On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:
>> Receive updates from SLOF about the updated rtas-base.
>> A separate patch for SLOF [1] (commit f9a60de3) 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>
>
> Ao I acked this earlier, but I've now realized there might be some
> connection between this and discussions taking place elsewhere about
> qemu not knowing what SLOF does with the device tree.
>
> At what point will SLOF call the UPDATE_RTAS hcall? I'm guessing at
> the time of instantiate-rtas, is that right?
The call happens from
arch/powerpc/kernel/prom_init.c:prom_instantiate_rtas() and after that
linux kernel makes two entries in the DT
....
if (call_prom_ret("call-method", 3, 2, &entry,
ADDR("instantiate-rtas"),
rtas_inst, base) != 0
|| entry == 0) {
prom_printf(" failed\n");
return;
}
prom_printf(" done\n");
reserve_mem(base, size);
val = cpu_to_be32(base);
prom_setprop(rtas_node, "/rtas", "linux,rtas-base",
&val, sizeof(val));
val = cpu_to_be32(entry);
prom_setprop(rtas_node, "/rtas", "linux,rtas-entry",
&val, sizeof(val));
....
Quiesce is called after this.
> Does SLOF put the RTAS blob address in its internal device tree, or
> does it only pass it to the guest via the return parameters from
> instantiate-rtas?
Entry was made to the DT by linux kernel prom_init code, will this be
visible to QEMU?
Regards,
Nikunj
On 29/09/17 21:52, Nikunj A Dadhania wrote:
> David Gibson <david@gibson.dropbear.id.au> writes:
>
>> On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:
>>> Receive updates from SLOF about the updated rtas-base.
>>> A separate patch for SLOF [1] (commit f9a60de3) 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>
>>
>> Ao I acked this earlier, but I've now realized there might be some
>> connection between this and discussions taking place elsewhere about
>> qemu not knowing what SLOF does with the device tree.
>>
>> At what point will SLOF call the UPDATE_RTAS hcall? I'm guessing at
>> the time of instantiate-rtas, is that right?
>
> The call happens from
> arch/powerpc/kernel/prom_init.c:prom_instantiate_rtas() and after that
> linux kernel makes two entries in the DT
>
> ....
> if (call_prom_ret("call-method", 3, 2, &entry,
> ADDR("instantiate-rtas"),
> rtas_inst, base) != 0
> || entry == 0) {
> prom_printf(" failed\n");
> return;
> }
> prom_printf(" done\n");
>
> reserve_mem(base, size);
>
> val = cpu_to_be32(base);
> prom_setprop(rtas_node, "/rtas", "linux,rtas-base",
> &val, sizeof(val));
> val = cpu_to_be32(entry);
> prom_setprop(rtas_node, "/rtas", "linux,rtas-entry",
> &val, sizeof(val));
> ....
>
> Quiesce is called after this.
>
>> Does SLOF put the RTAS blob address in its internal device tree, or
>> does it only pass it to the guest via the return parameters from
>> instantiate-rtas?
>
> Entry was made to the DT by linux kernel prom_init code, will this be
> visible to QEMU?
With my recent SLOF FDT patch - yes:
aik@fstn1-p1:~$ grep rtas dbg.dts
rtas {
linux,rtas-entry = <0x2fff0000>;
linux,rtas-base = <0x2fff0000>;
[...]
--
Alexey
On Mon, Oct 02, 2017 at 02:02:19PM +1100, Alexey Kardashevskiy wrote:
> On 29/09/17 21:52, Nikunj A Dadhania wrote:
> > David Gibson <david@gibson.dropbear.id.au> writes:
> >
> >> On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:
> >>> Receive updates from SLOF about the updated rtas-base.
> >>> A separate patch for SLOF [1] (commit f9a60de3) 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>
> >>
> >> Ao I acked this earlier, but I've now realized there might be some
> >> connection between this and discussions taking place elsewhere about
> >> qemu not knowing what SLOF does with the device tree.
> >>
> >> At what point will SLOF call the UPDATE_RTAS hcall? I'm guessing at
> >> the time of instantiate-rtas, is that right?
> >
> > The call happens from
> > arch/powerpc/kernel/prom_init.c:prom_instantiate_rtas() and after that
> > linux kernel makes two entries in the DT
> >
> > ....
> > if (call_prom_ret("call-method", 3, 2, &entry,
> > ADDR("instantiate-rtas"),
> > rtas_inst, base) != 0
> > || entry == 0) {
> > prom_printf(" failed\n");
> > return;
> > }
> > prom_printf(" done\n");
> >
> > reserve_mem(base, size);
> >
> > val = cpu_to_be32(base);
> > prom_setprop(rtas_node, "/rtas", "linux,rtas-base",
> > &val, sizeof(val));
> > val = cpu_to_be32(entry);
> > prom_setprop(rtas_node, "/rtas", "linux,rtas-entry",
> > &val, sizeof(val));
> > ....
> >
> > Quiesce is called after this.
> >
> >> Does SLOF put the RTAS blob address in its internal device tree, or
> >> does it only pass it to the guest via the return parameters from
> >> instantiate-rtas?
> >
> > Entry was made to the DT by linux kernel prom_init code, will this be
> > visible to QEMU?
>
> With my recent SLOF FDT patch - yes:
>
> aik@fstn1-p1:~$ grep rtas dbg.dts
> rtas {
> linux,rtas-entry = <0x2fff0000>;
> linux,rtas-base = <0x2fff0000>;
> [...]
Ah.. except.. isn't that relying on the kernel putting the RTAS
address into the device tree before it calls quiesce and kills SLOF?
The SLOF image is bundled in with qemu, so it's ok for us to rely on
its behaviour up to a point. It's not really ok for us to rely on the
kernel's behaviour here, unless that behaviour is mandated by PAPR,
which this isn't.
So, I think we either need to have *SLOF* update the device tree with
that address at instantiate-rtas time, or we'll need to resurrect
Aravinda's original UPDATE_RTAS hcall.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
On 03/10/17 17:07, David Gibson wrote:
> On Mon, Oct 02, 2017 at 02:02:19PM +1100, Alexey Kardashevskiy wrote:
>> On 29/09/17 21:52, Nikunj A Dadhania wrote:
>>> David Gibson <david@gibson.dropbear.id.au> writes:
>>>
>>>> On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:
>>>>> Receive updates from SLOF about the updated rtas-base.
>>>>> A separate patch for SLOF [1] (commit f9a60de3) 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>
>>>>
>>>> Ao I acked this earlier, but I've now realized there might be some
>>>> connection between this and discussions taking place elsewhere about
>>>> qemu not knowing what SLOF does with the device tree.
>>>>
>>>> At what point will SLOF call the UPDATE_RTAS hcall? I'm guessing at
>>>> the time of instantiate-rtas, is that right?
>>>
>>> The call happens from
>>> arch/powerpc/kernel/prom_init.c:prom_instantiate_rtas() and after that
>>> linux kernel makes two entries in the DT
>>>
>>> ....
>>> if (call_prom_ret("call-method", 3, 2, &entry,
>>> ADDR("instantiate-rtas"),
>>> rtas_inst, base) != 0
>>> || entry == 0) {
>>> prom_printf(" failed\n");
>>> return;
>>> }
>>> prom_printf(" done\n");
>>>
>>> reserve_mem(base, size);
>>>
>>> val = cpu_to_be32(base);
>>> prom_setprop(rtas_node, "/rtas", "linux,rtas-base",
>>> &val, sizeof(val));
>>> val = cpu_to_be32(entry);
>>> prom_setprop(rtas_node, "/rtas", "linux,rtas-entry",
>>> &val, sizeof(val));
>>> ....
>>>
>>> Quiesce is called after this.
>>>
>>>> Does SLOF put the RTAS blob address in its internal device tree, or
>>>> does it only pass it to the guest via the return parameters from
>>>> instantiate-rtas?
>>>
>>> Entry was made to the DT by linux kernel prom_init code, will this be
>>> visible to QEMU?
>>
>> With my recent SLOF FDT patch - yes:
>>
>> aik@fstn1-p1:~$ grep rtas dbg.dts
>> rtas {
>> linux,rtas-entry = <0x2fff0000>;
>> linux,rtas-base = <0x2fff0000>;
>> [...]
>
> Ah.. except.. isn't that relying on the kernel putting the RTAS
> address into the device tree before it calls quiesce and kills SLOF?
>
> The SLOF image is bundled in with qemu, so it's ok for us to rely on
> its behaviour up to a point. It's not really ok for us to rely on the
> kernel's behaviour here, unless that behaviour is mandated by PAPR,
> which this isn't.
Fair point.
> So, I think we either need to have *SLOF* update the device tree with
> that address at instantiate-rtas time,
I can do that, in a separate patch.
> or we'll need to resurrect
> Aravinda's original UPDATE_RTAS hcall.
--
Alexey
On 03/10/17 20:12, Alexey Kardashevskiy wrote:
> On 03/10/17 17:07, David Gibson wrote:
>> On Mon, Oct 02, 2017 at 02:02:19PM +1100, Alexey Kardashevskiy wrote:
>>> On 29/09/17 21:52, Nikunj A Dadhania wrote:
>>>> David Gibson <david@gibson.dropbear.id.au> writes:
>>>>
>>>>> On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:
>>>>>> Receive updates from SLOF about the updated rtas-base.
>>>>>> A separate patch for SLOF [1] (commit f9a60de3) 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>
>>>>>
>>>>> Ao I acked this earlier, but I've now realized there might be some
>>>>> connection between this and discussions taking place elsewhere about
>>>>> qemu not knowing what SLOF does with the device tree.
>>>>>
>>>>> At what point will SLOF call the UPDATE_RTAS hcall? I'm guessing at
>>>>> the time of instantiate-rtas, is that right?
>>>>
>>>> The call happens from
>>>> arch/powerpc/kernel/prom_init.c:prom_instantiate_rtas() and after that
>>>> linux kernel makes two entries in the DT
>>>>
>>>> ....
>>>> if (call_prom_ret("call-method", 3, 2, &entry,
>>>> ADDR("instantiate-rtas"),
>>>> rtas_inst, base) != 0
>>>> || entry == 0) {
>>>> prom_printf(" failed\n");
>>>> return;
>>>> }
>>>> prom_printf(" done\n");
>>>>
>>>> reserve_mem(base, size);
>>>>
>>>> val = cpu_to_be32(base);
>>>> prom_setprop(rtas_node, "/rtas", "linux,rtas-base",
>>>> &val, sizeof(val));
>>>> val = cpu_to_be32(entry);
>>>> prom_setprop(rtas_node, "/rtas", "linux,rtas-entry",
>>>> &val, sizeof(val));
>>>> ....
>>>>
>>>> Quiesce is called after this.
>>>>
>>>>> Does SLOF put the RTAS blob address in its internal device tree, or
>>>>> does it only pass it to the guest via the return parameters from
>>>>> instantiate-rtas?
>>>>
>>>> Entry was made to the DT by linux kernel prom_init code, will this be
>>>> visible to QEMU?
>>>
>>> With my recent SLOF FDT patch - yes:
>>>
>>> aik@fstn1-p1:~$ grep rtas dbg.dts
>>> rtas {
>>> linux,rtas-entry = <0x2fff0000>;
>>> linux,rtas-base = <0x2fff0000>;
>>> [...]
>>
>> Ah.. except.. isn't that relying on the kernel putting the RTAS
>> address into the device tree before it calls quiesce and kills SLOF?
>>
>> The SLOF image is bundled in with qemu, so it's ok for us to rely on
>> its behaviour up to a point. It's not really ok for us to rely on the
>> kernel's behaviour here, unless that behaviour is mandated by PAPR,
>> which this isn't.
>
> Fair point.
>
>> So, I think we either need to have *SLOF* update the device tree with
>> that address at instantiate-rtas time,
>
> I can do that, in a separate patch.
One comment though - if I create the properties in SLOF, I have to name
them different, like rtas-entry/rtas-base or slof,rtas-entry/slof,rtas-base
to avoid colliding with the ones create by the guest kernel.
So what do I name them? And do we need 2 copies of the same thing, do we
ever expect rtas-entry!=rtas-base? The guest can potentially get them
different (under powervm) but not with SLOF.
>
>> or we'll need to resurrect
>> Aravinda's original UPDATE_RTAS hcall.
--
Alexey
On Wed, Oct 04, 2017 at 02:32:11PM +1100, Alexey Kardashevskiy wrote:
> On 03/10/17 20:12, Alexey Kardashevskiy wrote:
> > On 03/10/17 17:07, David Gibson wrote:
> >> On Mon, Oct 02, 2017 at 02:02:19PM +1100, Alexey Kardashevskiy wrote:
> >>> On 29/09/17 21:52, Nikunj A Dadhania wrote:
> >>>> David Gibson <david@gibson.dropbear.id.au> writes:
> >>>>
> >>>>> On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:
> >>>>>> Receive updates from SLOF about the updated rtas-base.
> >>>>>> A separate patch for SLOF [1] (commit f9a60de3) 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>
> >>>>>
> >>>>> Ao I acked this earlier, but I've now realized there might be some
> >>>>> connection between this and discussions taking place elsewhere about
> >>>>> qemu not knowing what SLOF does with the device tree.
> >>>>>
> >>>>> At what point will SLOF call the UPDATE_RTAS hcall? I'm guessing at
> >>>>> the time of instantiate-rtas, is that right?
> >>>>
> >>>> The call happens from
> >>>> arch/powerpc/kernel/prom_init.c:prom_instantiate_rtas() and after that
> >>>> linux kernel makes two entries in the DT
> >>>>
> >>>> ....
> >>>> if (call_prom_ret("call-method", 3, 2, &entry,
> >>>> ADDR("instantiate-rtas"),
> >>>> rtas_inst, base) != 0
> >>>> || entry == 0) {
> >>>> prom_printf(" failed\n");
> >>>> return;
> >>>> }
> >>>> prom_printf(" done\n");
> >>>>
> >>>> reserve_mem(base, size);
> >>>>
> >>>> val = cpu_to_be32(base);
> >>>> prom_setprop(rtas_node, "/rtas", "linux,rtas-base",
> >>>> &val, sizeof(val));
> >>>> val = cpu_to_be32(entry);
> >>>> prom_setprop(rtas_node, "/rtas", "linux,rtas-entry",
> >>>> &val, sizeof(val));
> >>>> ....
> >>>>
> >>>> Quiesce is called after this.
> >>>>
> >>>>> Does SLOF put the RTAS blob address in its internal device tree, or
> >>>>> does it only pass it to the guest via the return parameters from
> >>>>> instantiate-rtas?
> >>>>
> >>>> Entry was made to the DT by linux kernel prom_init code, will this be
> >>>> visible to QEMU?
> >>>
> >>> With my recent SLOF FDT patch - yes:
> >>>
> >>> aik@fstn1-p1:~$ grep rtas dbg.dts
> >>> rtas {
> >>> linux,rtas-entry = <0x2fff0000>;
> >>> linux,rtas-base = <0x2fff0000>;
> >>> [...]
> >>
> >> Ah.. except.. isn't that relying on the kernel putting the RTAS
> >> address into the device tree before it calls quiesce and kills SLOF?
> >>
> >> The SLOF image is bundled in with qemu, so it's ok for us to rely on
> >> its behaviour up to a point. It's not really ok for us to rely on the
> >> kernel's behaviour here, unless that behaviour is mandated by PAPR,
> >> which this isn't.
> >
> > Fair point.
> >
> >> So, I think we either need to have *SLOF* update the device tree with
> >> that address at instantiate-rtas time,
> >
> > I can do that, in a separate patch.
>
>
> One comment though - if I create the properties in SLOF, I have to name
> them different, like rtas-entry/rtas-base or slof,rtas-entry/slof,rtas-base
> to avoid colliding with the ones create by the guest kernel.
That's fine. I don't know if the kernel will error if the properties
are already there or just overwrite them, but using new names might be
safer.
> So what do I name them? And do we need 2 copies of the same thing,
Need, no, but if having 2 copies is the simpler approach that's fine.
> do we
> ever expect rtas-entry!=rtas-base? The guest can potentially get them
> different (under powervm) but not with SLOF.
More to the point, qemu doesn't actually need to know the entry point
for the fwnmi stuff, only the base address.
>
>
> >
> >> or we'll need to resurrect
> >> Aravinda's original UPDATE_RTAS hcall.
>
>
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
On Friday 29 September 2017 11:47 AM, David Gibson wrote:
> On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:
>> Receive updates from SLOF about the updated rtas-base.
>> A separate patch for SLOF [1] (commit f9a60de3) 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>
>
> Ao I acked this earlier, but I've now realized there might be some
> connection between this and discussions taking place elsewhere about
> qemu not knowing what SLOF does with the device tree.
>
> At what point will SLOF call the UPDATE_RTAS hcall? I'm guessing at
> the time of instantiate-rtas, is that right?
>
> Does SLOF put the RTAS blob address in its internal device tree, or
> does it only pass it to the guest via the return parameters from
> instantiate-rtas?
The new set of patches posted by Alexey exports RTAS address via device
tree to QEMU. Once this is in, I will remove this patch and rebase the
rest of the patches.
Regards,
Aravinda
>
>> ---
>> hw/ppc/spapr.c | 11 +++++++++++
>> hw/ppc/spapr_hcall.c | 8 ++++++++
>> include/hw/ppc/spapr.h | 4 +++-
>> 3 files changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>> index ff87f15..5deae30 100644
>> --- a/hw/ppc/spapr.c
>> +++ b/hw/ppc/spapr.c
>> @@ -1675,6 +1675,16 @@ static const VMStateDescription vmstate_spapr_patb_entry = {
>> },
>> };
>>
>> +static const VMStateDescription vmstate_spapr_rtas_addr = {
>> + .name = "spapr_rtas_addr",
>> + .version_id = 1,
>> + .minimum_version_id = 1,
>> + .fields = (VMStateField[]) {
>> + VMSTATE_UINT64(rtas_addr, sPAPRMachineState),
>> + VMSTATE_END_OF_LIST()
>> + },
>> +};
>> +
>> static const VMStateDescription vmstate_spapr = {
>> .name = "spapr",
>> .version_id = 3,
>> @@ -1694,6 +1704,7 @@ static const VMStateDescription vmstate_spapr = {
>> &vmstate_spapr_ov5_cas,
>> &vmstate_spapr_patb_entry,
>> &vmstate_spapr_pending_events,
>> + &vmstate_spapr_rtas_addr,
>> NULL
>> }
>> };
>> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
>> index 8d72bb7..c15a93c 100644
>> --- a/hw/ppc/spapr_hcall.c
>> +++ b/hw/ppc/spapr_hcall.c
>> @@ -1088,6 +1088,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)
>> {
>> @@ -1750,6 +1757,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 c1b365f..b395aa7 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;
>> @@ -400,7 +401,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;
>>
>
--
Regards,
Aravinda
© 2016 - 2026 Red Hat, Inc.