Re: Aarch64 stand-alone application for Xen

[Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>]

On Wed, 8 Dec 2021 at 07:19, Michal Orzel <michal.orzel@xxxxxxx> wrote:
>
> Hi Mathieu,
>
> On 08.12.2021 01:06, Mathieu Poirier wrote:
> > Hi Bertrand,
> >
> > On Fri, 26 Nov 2021 at 03:32, Bertrand Marquis <Bertrand.Marquis@xxxxxxx> 
> > wrote:
> >>
> >> Hi Mathieu,
> >>
> >>> On 25 Nov 2021, at 22:59, Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> 
> >>> wrote:
> >>>
> >>> Good day,
> >>>
> >>> I am in the process of adding support for aarch64 to the xen-sys
> >>> crate[1].  The crate currently supports x86_64 and includes a
> >>> stand-alone "oxerun" application that can be used to validate
> >>> hypercalls.  My goal is to provide the same functionality on arm64.  I
> >>> am looking for a stand-alone aarch64 example, something like an "hello
> >>> world" to help me with the assembler startup code.
> >>
> >> We are working on porting XTF to arm64 and already have something running.
> >> I think it could be a good starting point for you:
> >> https://github.com/orzelmichal/xtf/tree/arm-devel
> >
> > Quick one - have you been able to get the "test-arm-64le-example"
> > application to run?  So far Xen gives me the following error:
> >
> > (XEN) ****************************************
> > (XEN) Panic on CPU 0:
> > (XEN) Unable to copy the kernel in the hwdom memory
> > (XEN) ****************************************
> >
> > I wanted to check with you before starting to dig into it.
> >
>
> ICYDK, 64le environment is used to create non-MMU domain in contrast to 
> mmu64le.

Right.

> It lacks support for PV console and other important features of Xen.

I'm good with that - for now all I want is to test hypervisor calls I
developed in Rust.

> But we are able to run it without any issue.
> Please keep in mind that as there is no MMU you need to pay attention to the 
> load address.
> By default for non-MMU domain, the address is 0x40000000 which is the correct 
> address if you use XTF as a guest.

I was trying to boot XTF as dom0 using the default address
(0x40000000), which lead to the output depicted above.

> If you want to run non-MMU XTF as dom0, you need to specify the correct load 
> address by passing CONFIG_LOAD_ADDRESS=<address>
> when invoking make. For example on QEMU it would be 
> CONFIG_LOAD_ADDRESS=0x80000000.
>

When adding the compilation flag "CONFIG_LOAD_ADDRESS=0x80000000" I
get further [1].  For my own education, why is address 0x80000000
required when running a non-MMU XTF as dom0?  Is this a Xen thing?

The application crashes in the loop on line 135 [2] and I am wondering
if it wouldn't be related to the QEMU emulation. My setup is as
follow:

. QEMU startup command [3]
. XTF baseline: "c14f7dd289a4 (xtf: Add arm support into xtf-runner)"
. Xen baseline: "c76cfada1cfa (tools/libacpi: Use 64-byte alignment for FACS)"

Best regards,
Mathieu

[1]. https://pastebin.com/3AVXRGXD
[2]. 
https://github.com/orzelmichal/xtf/blob/arm-devel/arch/arm/arm64/head.S#L135
[3]. https://pastebin.com/52aVAFha

> > Thanks,
> > Mathieu
> >
> >>
> >> Regards
> >> Bertrand
> >>
> >>>
> >>> Many thanks for the consideration,
> >>> Mathieu
> >>>
> >>> [1]. https://crates.io/crates/xen-sys
> >>>
> >>
> >
> Cheers,
> Michal