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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-12-12 at 13:55 +0000, Julien Grall wrote:
> > 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?
> 
> It's not clear to me what is the usage of XEN_ELFNOTE_PADDR_OFFSET. Is 
> it the physical address? An offset?

/*
 * The offset of the ELF paddr field from the actual required
 * pseudo-physical address (numeric).
 *
 * This is used to maintain backwards compatibility with older kernels
 * which wrote __PAGE_OFFSET into that field. This field defaults to 0
 * if not present.
 *
 * LEGACY: ELF_PADDR_OFFSET. (n.b. legacy default is VIRT_BASE)
 */
#define XEN_ELFNOTE_PADDR_OFFSET   4

So apparently it is the offset between the paddr field in the ELF file
and the real load address. Which seems like it should be
0xc0100000-0x80100000, but you'll have to UTSL to be sure.

> > 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.
> 
> FreeBSD requires to know at compile time the RAM base address. I think 
> it's fine now to hardcode to GUEST_RAMBASE. We can modify it later.

OK, that makes it easier for these headers to fit I think.

> >> 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.
> 
> That would mean we need to fix up every seg->vstart/vend.

Quite possible, yes.

This code was written to deal with a PV x86 guest, which has a different
set of requirements to what is needed on ARM.

>  The main issue 
> is, at the end of xc_dom_alloc_segment, we will store vend to 
> virt_alloc_end. This value we be retrieved to the next allocation..
> 
> I wrote the patch in this way because I think it's fine to do all the 
> allocation in the virtual address space (even if MMU is turn off during 
> at boot time) and then, thanks to xc_dom_alloc_segment, translate to 
> physical address. It's the currently behaviour. But it works fine 
> because for zImage, we made the assumption that virt_base == rambase_pfn 
> << PAGE_SHIFT.

The fact that the fields are called virt_* is irrelevant, these are
physical addresses on ARM, the naming is from x86 where they are
physical addresses.

If you are trying to somehow shoehorn the kernels virtual addresses into
these then things will get confusing fast. Everything should be thought
of in terms of physical addresses and the *load* address that BSD
expects. 

> The main change is using virt_base to allocate the device tree and 
> substract different offset when the guest will start.

If this is done correctly then virt_base will contain physical addresses
and everything works without offsets.

Ignore the field names and think only about physical addresses.

> >>>>   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.
> 
> Most of the code is writing PIC. But as in Linux, for assembly code you 
> can have something like that:
> 
> .word my_func
> 
> my_func will be replaced by the virtual address not the physical 
> address. So when the kernel want to call the function with MMU disabled, 
> it will need to add an offset. Thankfully, you don't need it everywhere.

That's not PIC code then. PIC code would have an offset not an address
and would call the function as the offset from current PC or something
similar, but we are digressing here.

Ian.


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