[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 14/15] libxl: build a device tree for ARM guests
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |