Re: [Xen-devel] [PATCH for-4.12 v2 2/2] xen/arm: Stop relocating Xen

[Julien Grall <Julien.Grall@xxxxxxx>]

On 12/14/18 3:52 PM, Andrii Anisov wrote:
> Hello Julien,

Hi,

>
> Let me speculate a bit about the topic.
>
> On 14.12.18 13:44, Julien Grall wrote:
>> At the moment, Xen is relocated towards the end of the memory.
> This statement is not really true. Some time ago, XEN was relocated
> toward the end of
> the low memory (under 4 GB).
Are you using arm64 or arm32? Arm64 does not have the 4GB limit while Arm32 has.
I could make the difference in the commit message but this would add more
confusion below.

> Currently, on my board I see some kind of
> mess:
>
>      (XEN) RAM: 0000000048000000 - 00000000bfffffff
>      (XEN) RAM: 0000000500000000 - 000000057fffffff
>      (XEN) RAM: 0000000600000000 - 000000067fffffff
>      (XEN) RAM: 0000000700000000 - 000000077fffffff
>      (XEN)
>      (XEN) MODULE[0]: 0000000048000000 - 0000000048013000 Device Tree
>      (XEN) MODULE[1]: 000000007a000000 - 000000007c000000 Kernel
>      (XEN) MODULE[2]: 000000007c000000 - 000000007c010000 XSM
>      (XEN)  RESVD[0]: 0000000048000000 - 0000000048013000
>      (XEN)
>      (XEN)
>      (XEN) Command line: dom0_mem=3G console=dtuart dtuart=serial0
> dom0_max_vcpus=2 bootscrub=0 loglvl=all cpufreq=none tbuf_size=8192
> loglvl=all/none guest_loglvl=all/none
>      (XEN) parameter "cpufreq" unknown!
>      (XEN) Placing Xen at 0x000000077fe00000-0x0000000780000000
>      (XEN) Update BOOTMOD_XEN from 0000000078080000-0000000078188d81 =>
> 000000077fe00000-000000077ff08d81
>
> As you can see XEN is moved towards the end of the first GB of the low
> memory instead of the end of under 4GB RAM.

I don't understand what you mean. Looking at your log, Xen is relocated at the
end of the last bank. This is the expected behavior in unstable.
>> While
>> this has the advantage to free space in low memory, the code is not
>> compliant with the break-before-make because it requires to switch
>> between two sets of page-table. This is not entirely trivial to fix as
>> it would require us to go through an identity mapping and disabling MMU.
> I understand this motivation though.
>
>> Furthermore, it looks like that some platform (such as the Hikey960)
>> may not be able to bring-up secondary CPUs if the entry is too
>> high.Just a reminder that long time ago we implemented a move of XEN
>> toward the real end of the memory, over 4GB.

This not the first time part of answer is mangled with my e-mail. This is making
really difficult to follow the conversion. Can you please configure your e-mail
client to do proper quote/reply?

> As long as CPUs were not able to start to the code placed over 4 GB, we
> set secondary CPUs to be brought up to a XEN instance under 4GB, then
> jump to a copy over 4GB, following CPU0.

How were you switching between the page-tables? A proper solution would require
to switch between page-tables using an identify mappings. This is far more
complicate than what is worth here.

>
>> I don't believe the low memory is an issue because Xen is quite tiny
>> (< 2MB).
> It is really tiny, but the problem is that Dom0 low memory (lower than 4
> GB) RAM banks
> start and end are aligned by 128MB. So existing of a single 1MB XEN cuts
> out 128MB from low memory for Dom0.

I don't understand how you came up with the conclusion that 128MB will be
removed from Dom0. We only have the requirement that the first bank is at least
128MB. So can you expand it?

> On my current setup I have two 128MB chunks stolen: one by relocated
> XEN, kernel module an XSM module, other another by device tree.

Xen is free to allocate anything below 4GB. This is nothing new. But you should
not have two 128MB chunks stolen because of modules here. If that's the case
then there is a bug in Xen that should be fixed.

Cheers,

--
Julien Grall
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel