Zachary Amsden wrote:
> /*
> * __xen_guest information
> */
> .macro utoa value
> .if (\value) < 0 || (\value) >= 0x10
> utoa (((\value)>>4)&0x0fffffff)
> .endif
> .if ((\value) & 0xf) < 10
> .byte '0' + ((\value) & 0xf)
> .else
> .byte 'A' + ((\value) & 0xf) - 10
> .endif
> .endm
This is very ugly, I agree. The big problem with encoding addresses
into strings this way is that it prevents us from referring to
linker-computed addresses, meaning we have to place things with .org
rather than letting them fall where they may.
> .section __xen_guest
> .ascii "GUEST_OS=linux,GUEST_VER=2.6"
> .ascii ",XEN_VER=xen-3.0"
> .ascii ",VIRT_BASE=0x"
> utoa __PAGE_OFFSET
> .ascii ",HYPERCALL_PAGE=0x"
> utoa
> ((__PHYSICAL_START+HYPERCALL_PAGE_OFFSET)>>PAGE_SHIFT)
> .ascii ",FEATURES=writable_page_tables"
> .ascii "|writable_descriptor_tables"
> .ascii "|auto_translated_physmap"
> .ascii "|pae_pgdir_above_4gb"
> .ascii "|supervisor_mode_kernel"
> #ifdef CONFIG_X86_PAE
> .ascii ",PAE=yes"
> #else
> .ascii ",PAE=no"
> #endif
> .ascii ",LOADER=generic"
> .byte 0
But this, or something like it, needs to stay. We have to have a way
for the domain builder to inspect the kernel and determine whether it
can actually make a viable domain for it, and if so, be able to set up
the basic environment properly. For example, if the kernel is PAE, we
need to reserve a larger address space hole than for a non-PAE kernel.
And the kernel can't even make a hypercall unless there is some way to
communicate where the hypercall page should be.
I don't see this as being any more ad-hoc or harder to maintain than a
series of Xen hypercalls to negotate all this between Xen and the
kernel, assuming its even possible. In fact, this seems a fair bit more
straightforward and easier to maintain. Either way, it is all squarely
in the Xen-specific parts of the code, so its not like it leaks out to
have global impact.
J
