Re: Aarch64 stand-alone application for Xen

[Michal Orzel <michal.orzel@xxxxxxx>]

Hi Mathieu,

On 08.12.2021 22:23, Mathieu Poirier wrote:
> 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
> 

For the setup you provided just compile XTF with CONFIG_LOAD_ADDRESS=0x60000000.
This will fix your problem.
When using non-MMU dom0, the microkernel must be compiled with the load address 
that
is within the memory bank allocated by Xen. You can see it in your logs:
(XEN) BANK[0] 0x00000060000000-0x00000080000000 (512MB)

You did not specify dom0_mem parameter, so Xen defaults to 512MB for dom0.
You can see it in your logs:
(XEN) PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR NOW

FWICS you are passing Xen command line arguments through -append but i'm not 
sure it works.
The best way is to use dtb.


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

Cheers,
Michal