[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH v5 1/6] ppc: spapr: Register and handle HCALL to r
From: |
Nikunj A Dadhania |
Subject: |
Re: [Qemu-ppc] [PATCH v5 1/6] ppc: spapr: Register and handle HCALL to receive updated RTAS region |
Date: |
Fri, 29 Sep 2017 17:22:22 +0530 |
David Gibson <address@hidden> 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 <address@hidden>
>> Reviewed-by: David Gibson <address@hidden>
>
> 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
- [Qemu-ppc] [PATCH v5 0/6] target-ppc/spapr: Add FWNMI support in QEMU for PowerKVM guests, Aravinda Prasad, 2017/09/28
- [Qemu-ppc] [PATCH v5 1/6] ppc: spapr: Register and handle HCALL to receive updated RTAS region, Aravinda Prasad, 2017/09/28
- [Qemu-ppc] [PATCH v5 2/6] ppc: spapr: Handle "ibm, nmi-register" and "ibm, nmi-interlock" RTAS calls, Aravinda Prasad, 2017/09/28
- [Qemu-ppc] [PATCH v5 3/6] Wrapper function to wait on condition for the main loop mutex, Aravinda Prasad, 2017/09/28
- [Qemu-ppc] [PATCH v5 4/6] target/ppc: Handle NMI guest exit, Aravinda Prasad, 2017/09/28
- [Qemu-ppc] [PATCH v5 5/6] ppc: spapr: Enable FWNMI capability, Aravinda Prasad, 2017/09/28
- [Qemu-ppc] [PATCH v5 6/6] migration: Block migration while handling machine check, Aravinda Prasad, 2017/09/28
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v5 0/6] target-ppc/spapr: Add FWNMI support in QEMU for PowerKVM guests, no-reply, 2017/09/28