Re: [Xen-devel] [PATCH] libxc/arm: Correctly handle the difference between virtual and physical address

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-12-11 at 19:26 +0000, Julien Grall wrote:
> On 12/11/2013 10:02 AM, Ian Campbell wrote:
> > On Tue, 2013-12-10 at 18:16 +0000, Julien Grall wrote:
> >> This issue is when as virt == phys, build ELF with virt != phys is very 
> >> difficult.
> > 
> > OK, so I think I was mislead by your commit message, this is not
> > actually about virt vs phys as such (or as represented in the ELF
> > header) but is actually more about link address vs. load address. Where
> > link address == ELF vaddr (==paddr). And because the MMU is disable load
> > address == some vaddr (==paddr), which may differ from the ELF vaddr.
> > 
> > The terminology in xc_dom, which uses vaddr a lot because of PV x86,
> > isn't helpful here but is that an accurate summary?
> 
> Right, and this address is actually equal to ELF vaddr. But the device
> tree base address will be computed with the physical address.
> 
> > [...]
> >> When the guest is creating, the ELF should loaded like zImage at the 
> >> specific
> >> physical address.
> > 
> > So that would be my next question -- where does this load address come
> > from?
> 
> Load address ? Virtual ? Physical ?

Load address == The literal address where the kernel image is loaded,
e.g. on native it would be the physical address.

> > I suppose it has to be the 0x80100000 kernel physical address you gave
> > earlier?
> > 
> > I think this means "where is dom->parms.virt_base" initialised. Have you
> > added some ELF notes to your BSD kernel image?
> 
> I have tried to play with the ELF notes. My current configuration is:
> 
> XEN_ELFNOTE_VIRT_BASE    vaddr        (0xC0000000)
> XEN_ELFNOTE_PADDR_OFFSET vaddr                (0xC0000000)
> 
> It's copied from Linux.

XEN_ELFNOTE_PADDR_OFFSET is 0 for x86 Linux though.

It's possible that for ARM it should be RAMBASE or something? Or perhaps
it should be 0 and the RAMBASE should be added by the tools. Or maybe it
should be omitted and only VIRT_BASE is needed?

Does NetBSD absolutely require that it is loaded at precisely address
0x80100000 or is the requirement rambase + 0x00100000.

If NetBSD has requirements about where RAM is the we may need a new note
to designate the required RAM base address.

> If I try to modify PADDR_OFFSET with (KERNBASE - PHYSADDR) or whatever
> value it doesn't work. I got
> "segment kernel too large (0x355 > 0x4000 - 0x80100 pages): Out of memory".

It is very possible that the existing code buggily assumes in various
places that RAM starts at address 0, because it has only ever been run
on x86. You will probably need to fix this by using rambase_pfn in
various places.

> >>  Then the guest will start will MMU turn off, and during the
> >> first instructions it will use fixup to get the right address.
> > 
> > "fixup" == enable the MMU, or "fixup" == some sort of relocation/PIC?
> 
> Some sort of relocation. When MMU is turn off, every time the kernel
> needs to call asm callback, it will add an offset.

Sounds a bit mad to me compared with writing PIC, but OK.

Ian.



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