Re: Keystone Issue

[Julien Grall <julien@xxxxxxx>]

(+Bertrand and Stefano)

On 01/06/2020 18:38, CodeWiz2280 wrote:
> Hi Julien,
Hi Dave,

> As requested please see log below from the eval board booting dom0, some 
> notes are as follows:
Thanks for the logs and the notes. They are useful to understand your issue.

> 1. The offset that gets applied to the 32-bit address to translate it 
> to 36-bits is 0x7_8000_0000
Is this offset present in the Device-Tree?

> 2. Uboot has been setup to not change the address of the memory in the 
> device tree prior to launching xen, otherwise it would 
> automatically offset it and replace it with a 36-bit address and xen 
> would immediately panic at the 36-bit address for a 32-bit processor.
What is the list of the memory banks Xen will see?

Xen is able to support 36-bit address, can you point to the panic() you 
are hitting?
> 3. The RAM starting address placed in the device tree is 0x8000_0000, 
> which gets carved up by xen and replaced with 0xA000_0000 prior to 
> booting dom0..  I had to put in test code to have the kernel offset the 
> 0xA000_0000 32-bit starting address to the 36-bit address needed before 
> the kernel will attempt to switch.  If it stays 32-bit then it will not 
> switch over the address space.  Note that without xen in play uboot 
> would normally replace the address in the device tree with the 36-bit one.
IIUC, in the case of Linux boot directly, the Device-Tree will not 
describe the low memory range. Is that correct?
> 4. The dom0 kernel will boot from xen if the early_paging_init switch 
> step is skipped, and the low mem stays in 32-bit....but there is a 
> problem with the peripherals so this is not an acceptable solution.
Can you details a bit more the problem with the peripherals?

> It seems that either the kernel would need some API to tell xen that 
> there is going to be a change in the memory its using prior to call 
> early_paging_init(), 
From my understanding, the problem is very specific to the KeyStone. So 
I would rather avoid to introduce an hypercall specific to your 
platform. But...
> or Xen would need to add the additional 36-bit 
> addresses during the memory bank allocation step....but recognize that 
> they are not actually different physical memory but just aliased to a 
> different address.
... I think it is possible to fix it entirely in Xen without any 
modification in the device-tree.
It is seems better that Xen treats the low memory region as "not usable" 
and only use the high memory region internally. When allocating a Dom0 
memory banks, it would need to ensure that there is a corresponding 
alias in low memory.
Xen will also need to do two mappings in the Dom0 stage-2 page-tables. 
The extra one is for the alias.
This approach will prevent to use hypercall buffer from low memory and 
therefore require your guest to support LPAE. Is it going to be an issue 
for you?
Cheers,

--
Julien Grall