Re: [Xen-devel] [PATCH RFC 14/15] libxl: build a device tree for ARM guests

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-10-15 at 14:23 +0100, Julien Grall wrote:
> >>> +    res = fdt_property_cell(fdt, "cpu_on", 0x2);
> >>> +    if ( res )
> >>> +        return res;
> >>
> >> Can we export include/asm-arm/psci.h and reuse the value here?
> > 
> > I suppose we ought to, since Xen is the one implementing the actual
> > functionality. I notice that even Xen itself isn't using those #defines
> > (nothing is AFAICT!)
> 
> It's used in traps.c via in the macro PSCI and in domain_build.c when
> the PSCI node is creating.

Ah, macros ;-) Also I was grepping for __PSCI_cpu_suspend which isn't
used...

> 
> >>> +    //DPRINT("  Grant table range: 0xb0000000-0x20000\n");
> >>> +    /* reg 0 is grant table space */
> >>> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> >>> +                            1,
> >>> +                            (uint64_t)0xb0000000,
> >>
> >> I still don't know where this value comes from... if it's a random 
> >> value, can we autogenerate it?
> > 
> > It's an arbitrary value which we picked when we defined our guest
> > virtual platform. It's "random" in the same way as the address of the
> > UART picked by an SoC designer is.
> > 
> > It should be a #define for sure though.
> 
> If you choose to hardcode this address, can you add a TODO? So we won't
> forget later.

Unless you have a use case for making this value changeable there is
nothing wrong with us picking a number and using it, I don't think there
is any TODO here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel