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 <da...@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 <aravi...@linux.vnet.ibm.com> >>>>> Reviewed-by: David Gibson <da...@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
signature.asc
Description: OpenPGP digital signature