Re: [Xen-devel] Failed to enable MMU when booting EFI on Seattle

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-10-06 at 22:29 -0500, Suravee Suthikulpanit wrote:
> Ian/Roy,
> 
> So, I have found that in arch/arm/arm64/head.S, after we enable MMU and 
> execute "br x1" (where x1 = 0x2005F8, the VA of "paging:"), it went to 
> address 0x2005F8, which has all zeros value. This is why we getting the 
> "Synchronous Exception"
> 
> ......
> 1:
>          PRINT("- Turning on paging -\r\n")
> 
>          ldr   x1, =paging            /* Explicit vaddr, not RIP-relative */
>          mrs   x0, SCTLR_EL2
>          orr   x0, x0, #SCTLR_M       /* Enable MMU */
>          orr   x0, x0, #SCTLR_C       /* Enable D-cache */
>          dsb   sy                     /* Flush PTE writes and finish 
> reads */
>       b .
>          msr   SCTLR_EL2, x0          /* now paging is enabled */
>          isb                          /* Now, flush the icache */
>          br    x1                     /* Get a proper vaddr into PC */
> paging:
> .....
> 
> Notes:
> * This is not the case when booting non-EFI.
> 
> * If I do "add x1, x1, x20", which puts the PA of paging into x1, it 
> seems to branch to "paging:" fine. Although, I don't this this is the 
> right thing to do since it should already be using VA).
> 
> So, I inspected the page tables and compare the ones from booting with 
> and without EFI. At this point, it seems that the contents of the page 
> tables are set up properly. The only thing different is the phys-offset 
> and the location of the page table:
> 
> BOOTING WITH EFI:
> 
>       x20 (phys-offset) = 0x83fc2d0000
>       x19 (start paddr) = 0x83fc4d0000
>       (.text starts at 2MB = 0x200000 offset)
> 
>       boot_pgtable (pa) = x20 + 0x2f2000 = 0x83fc5c2000
>       boot_first (pa)   = x20 + 0x2f3000 = 0x83fc5c3000
>       boot_second(pa)   = x20 + 0x2f5000 = 0x83fc5c5000
>       boot_third (pa)   = x20 + 0x2f6000 = 0x83fc5c6000
> 
> BOOTING WITHOUT EFI:
> 
>       x20 (phys-offset) = 0x8008500000
>       x19 (start paddr) = 0x8008700000
>       (.text starts at 2MB = 0x200000 offset)
> 
>       boot_pgtable (pa) = x20 + 0x2f2000 = 0x80087f2000
>       boot_first (pa)   = x20 + 0x2f3000 = 0x80087f3000
>       boot_second(pa)   = x20 + 0x2f5000 = 0x80087f5000
>       boot_third (pa)   = x20 + 0x2f6000 = 0x80087f6000
> 
> Here is the memory map available from UEFI:
>       
> Shell> memmap
> Type      Start            End              #pages             Attributes
> RT_Data   0000008000000000-0000008000FFFFFF 0000000000001000 
> 800000000000000F
> Available 0000008001000000-0000008007FFDFFF 0000000000006FFE 
> 000000000000000F
> BS_Code   0000008007FFE000-0000008007FFFFFF 0000000000000002 
> 000000000000000F
> Available 0000008008000000-000000801FFFDFFF 0000000000017FFE 
> 000000000000000F
> BS_Data   000000801FFFE000-000000801FFFFFFF 0000000000000002 
> 000000000000000F
> Available 0000008020000000-000000802FFFFFFF 0000000000010000 
> 000000000000000F
> RT_Code   0000008030000000-0000008030000FFF 0000000000000001 
> 800000000000000F
> Available 0000008030001000-00000083F0FFFFFF 00000000003C0FFF 
> 000000000000000F
> BS_Data   00000083F1000000-00000083F101FFFF 0000000000000020 
> 000000000000000F
> Available 00000083F1020000-00000083FC5D2FFF 000000000000B5B3 
> 000000000000000F
> LoaderCode 00000083FC5D3000-00000083FC6B1FFF 00000000000000DF 
> 000000000000000F
> 
> However, it seems that the location falls in the "Available", which 
> should be ok to use.

Right, I don't see anything wrong with the location of the page tables.

What do the contents of these PTs look like?

In particular for Xen's load address of 0x200000 I think entries at
boot_pgtable[0], boot_first[0], boot_second[0] and boot_third[0x20] are
of interest. Do they correctly map their next level and/or the physical
address with the actual Xen bits in?

For completeness it would also be worth knowing the entries
corresponding to the 1:1 pa mapping.

For phys-offset 0x8008500000 those would be offsets [0x1, 0x0, 0x42,
0x100] (I think, but please do check my maths!). I think this will
result in boot_pgtable[1] mapping boot_first_id which will contain a
gigabyte page super mapping in slot [0].

Phys-offset 0x83fc2d0000 ought to be offsets [0x1, 0xf, 0x1e1, 0xd].
Which I would again expect to result in boot_pgtable[1] mapping
boot_first_id with a gigabyte mapping in slot 0xf this time.

I expect the PA mapping to be correct, since as you say we are able to
run off it, it's worth checking though in case we are somehow creating
VA and PA-1:1 mappings which conflict (e.g. writing boot_first instead
of boot_first_id when creating the PA mappings -- that sort of thing).

Ian.

> 
> Not sure at this point what I might be missing :(
> 
> Suravee
> 
> 



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