Re: [Xen-devel] Bare-metal Xen on ARM boot

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 29 Apr 2013, Ian Campbell wrote:
> On Sun, 2013-04-28 at 15:04 +0100, Stefano Stabellini wrote:
> > On Fri, 26 Apr 2013, Sander Bogaert wrote:
> > > >> I was getting the number from xen/arch/arm/traps.c:706 ''call =
> > > >> arm_hypercall_table[regs->r12].fn;" and the arm_hypercall_table in the
> > > >> same file. It should have been #4 by that reasoning I know.
> > > >
> > > > That macro is such that the fact that something appears at position N In
> > > > the list doesn't mean it is position N in the resulting array, it
> > > > expands into the syntax
> > > > array[] = {
> > > >         [1] = a_thing
> > > >         [4] = another_thing
> > > > }
> > > > which initialises slots 1 and 4.
> > > 
> > > Thanks, I overlooked that.
> > > 
> > > >>
> > > >> Also, I was trying an ELF file. I will try again tomorrow with a
> > > >> zImage header and report back.
> > > >>
> > > >> Thanks,
> > > >> Sander
> > > >
> > > >
> > > 
> > > ELF does seem to be supported but then it gets stuck further down in
> > > domain builder code ( I also attached the entire output) :
> > > 
> > > domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-unknown:
> > > 0x80000000 -> 0x80010010
> > > xc: error: panic: xc_dom_core.c:608: xc_dom_find_arch_hooks: not found
> > > (type xen-3.0-unknown): Invalid kernel
> > > xc: error: panic: xc_dom_core.c:763: xc_dom_mem_init: arch hooks not
> > > set: Internal error
> > > libxl: error: libxl_dom.c:384:libxl__build_pv: xc_dom_mem_init failed:
> > > No such file or directory
> > > 
> > > The vmlinux binary ( elf ) doesn't boot neither and has the same
> > > problem. Could it have something to do with:
> > > "xc: detail: elf_xen_note_check: Not bothering with notes on ARM"
> > > Missing metadata?
> > > 
> > > I'll focus on getting an zImage working.
> > 
> > The problem seems to be that dom->guest_type is set to
> > "xen-3.0-unknown" by xc_dom_guest_type at the end of
> > xc_dom_parse_elf_kernel.
> > In order to match the ARMv7 supported guest_type it should have been
> > "xen-3.0-armv7l", as you can see from
> > xc_dom_armzimageloader.c:xc_dom_parse_zimage_kernel.
> > 
> > Maybe we just need to add the appropriate case in the switch in
> > xc_dom_guest_type (see below)?
> 
> We certainly need to add something there, and your string seems as
> plausible as the next one ;-)
> 
> I suppose we need to handle EM_AARCH64 at some point too...
> 
> I reckon a warning print under the default case would have us then and
> other porters in the future...
> 
> > 
> > diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
> > index 6583859..911f316 100644
> > --- a/tools/libxc/xc_dom_elfloader.c
> > +++ b/tools/libxc/xc_dom_elfloader.c
> > @@ -74,6 +74,8 @@ static char *xc_dom_guest_type(struct xc_dom_image *dom,
> >          }
> >      case EM_X86_64:
> >          return "xen-3.0-x86_64";
> > +    case EM_ARM:
> > +        return "xen-3.0-armv7l";
> >      default:
> >          return "xen-3.0-unknown";
> >      }

Sander,
if you confirm that this change solved your problem, I'll resend as a
proper patch.

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