Re: [Xen-users] ARM: Xen on Vexpress

[Julien Grall <julien.grall@xxxxxxxxxx>]

(CCing Xen-devel)

On 06/16/2014 05:32 PM, Jeenu Viswambharan wrote:
> On Thu, Jun 12, 2014 at 15:50:02, Jeenu Viswambharan wrote:
>>>>   - What does DOM0 see as its PC at entry?
>>>
>>> The load address of the kernel image, since the zImage protocol
>>> requires us to enter the kernel at that offset.
>>
>> I managed to break at eret before guest entry, and the PC is
>> 0xafc00000 itself. It does fail to boot bare metal too from that
>> address. I'll see if I can find what's going wrong.
> 
> I've been told that loading Linux at that high an offset from the memory
> base wouldn't work after all, even on bare metal. I therefore set
> kernel_addr_r to 0x80008000, which makes Xen load DOM0 at 0x8fc00000. I
> can see Linux starting to boot from this address on bare metal, but With
> Xen I'm seeing "uncompression error" (not printed on to the console, but
> through debugger inspection).
> 
> I haven't pinned down why exactly it's throwing this. While I'm at it,
> I'd appreciate any helpful pointers.

Did you try to use CONFIG_VMSPLIT_3G rather than CONFIG_VMSPLIT_2G as I
suggested last week?

Using CONFIG_VMSPLIT_3G works correctly with 3.15. It looks like another
issue in the pa - virt delta when it's positive.

IIRC, it's because linux is assuming that delta is always negative (see
comment on __PV_BITS_31_24 in arch/arm/include/asm/memory.h).

At first glance, handling positive offset will be hard because, their
are rely on the compiler to provide the right layout for the
instruction. Positive number is not encoded the same way. I will have to
spend a bit more time to fully understand this code.

With Ian multiple bank support patch for DOM0, I think we can safely
assume that the delta will (nearly?) always be the same.

Regards,

-- 
Julien Grall

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