Re: [Xen-devel] [PATCH v4 16/17] libxl: build a device tree for ARM guests

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-11-12 at 19:59 +0000, Julien Grall wrote:
> 
> On 11/12/2013 05:39 PM, Ian Campbell wrote:
> > Uses xc_dom_devicetree_mem which was just added. The call to this needs to 
> > be
> > carefully sequenced to be after xc_dom_parse_image (so we can tell which 
> > kind
> > of guest we are building, although we don't use this yet) and before
> > xc_dom_mem_init which tries to decide where to place the FDT in guest RAM.
> >
> > Removes libxl_noarch which would only have been used by IA64 after this
> > change. Remove IA64 as part of this patch.
> >
> > There is no attempt to expose this as a configuration setting for the user.
> >
> > Includes a debug hook to dump the dtb to a file for inspection.
> >
> > TODO:
> > - v7 CPU compat is hardcoded to cortex-a15 -- may need to define something 
> > more
> >    generic via mach-virt dt bindngs?
> >
> > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > ---
> > v4: Drop spurious comment in header
> >      s/__be32/be32/ and s/gic_interrupt_t/gic_interrupt/ to avoid reserved 
> > names
> >      Coding style fixes
> >      Use GCSPRINTF
> >      use for(;;) around FDT creation loop, undef FDT when done
> >      use libxl__realloc for fdt size increase
> >      Refactor debug dump into its own function, remove NDEBUG ifdef
> > v2: base addresses, irq, evtchn etc stuff is now from public API headers,
> >      avoiding the need to introduce domctls etc until we want to make them
> >      dynamic.
> >      fix memory node
> >      Improve libfdt error handling, especially for FDT_ERR_NOSPACE.
> >      Derive guest CPU and timer compatiblity nodes from the guest type.
> > ---
> >   tools/libxl/Makefile       |    6 +-
> >   tools/libxl/libxl_arch.h   |    3 +
> >   tools/libxl/libxl_arm.c    |  516 
> > ++++++++++++++++++++++++++++++++++++++++++++
> >   tools/libxl/libxl_dom.c    |    4 +
> >   tools/libxl/libxl_noarch.c |    8 -
> >   tools/libxl/libxl_x86.c    |    7 +
> >   6 files changed, 534 insertions(+), 10 deletions(-)
> >   create mode 100644 tools/libxl/libxl_arm.c
> >   delete mode 100644 tools/libxl/libxl_noarch.c
> 
> [..]
> 
> > diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> > new file mode 100644
> > index 0000000..9fe9a81
> > --- /dev/null
> > +++ b/tools/libxl/libxl_arm.c
> > @@ -0,0 +1,516 @@
> > +#include "libxl_internal.h"
> > +#include "libxl_arch.h"
> > +
> > +#include <xc_dom.h>
> > +#include <libfdt.h>
> > +#include <assert.h>
> > +
> > +int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> > +                              uint32_t domid)
> > +{
> > +    return 0;
> > +}
> > +
> > +static struct arch_info {
> > +    const char *guest_type;
> > +    const char *timer_compat;
> > +    const char *cpu_compat;
> > +} arch_info[] = {
> > +    {"xen-3.0-armv7l",  "arm,armv7-timer", "arm,cortex-a15" },
> 
> What about "arm,armv7" instead arm,cortex-a15? It's more accurate as 
> it's possible to boot Xen on cortex-a7 core.

I don't think that is a defined compat string though.

I think this probably needs resolving either by extending the mach-virt
"spec" to cover a common generic CPU type or by somehow exposing the
physical CPU compatibility string to the tools.



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