Re: [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit v2

From: Jeremy Fitzhardinge
Date: Tue Mar 04 2008 - 12:17:05 EST


Alexander van Heukelum wrote:
On Tue, 04 Mar 2008 07:18:48 -0800, "Jeremy Fitzhardinge"
<jeremy@xxxxxxxx> said:
Mark McLoughlin wrote:
This is a bit magic, is it worth splitting it out as something like
is_paravirt_environment() ?
Yes, is_paravirt() already exists for this purpose.

Hi,

If it exists, it is well-hidden. A grep for is_paravirt on the testing
tree turns up nothing. Did you get the name right?

Nope. paravirt_enabled().

The code looking at the boot params will only work if we actually booted via the paravirt Linux boot protocol, which Xen doesn't at present.

I chose to code it exactly this way, because it is what is used in
head_32.S to choose how to start the kernel. Or is this code not
executed at all?

No, this isn't executed when booting under Xen. Xen is a bit magic, and has its own kernel entrypoint which the domain builder finds via Xen-specific ELF notes on the vmlinux. We plan to move to booting via this path at some point.

[excerpt form head_32.S]
cmpw $0x207, pa(boot_params + BP_version)
jb default_entry

/* Paravirt-compatible boot parameters. Look to see what
architecture
we're booting under. */
movl pa(boot_params + BP_hardware_subarch), %eax
cmpl $num_subarch_entries, %eax
jae bad_subarch

movl pa(subarch_entries)(,%eax,4), %eax
subl $__PAGE_OFFSET, %eax
jmp *%eax
[and]
subarch_entries:
.long default_entry /* normal x86/PC */
.long lguest_entry /* lguest hypervisor */
.long xen_entry /* Xen hypervisor */
num_subarch_entries = (. - subarch_entries) / 4
[end]

If this is indeed not executed, is there a way to detect whether
we can expect the environment to behave like a normal pc in terms
of magic addresses, bios areas, isa reserved address space and so
on?

Just because something is paravirtualized and uses a non-PC hardware_subarch doesn't mean this stuff isn't present. Even the paravirt_enabled() test isn't accurate, because the environment may still choose to emulate these things (or in the Xen dom0 case, it may directly expose the real hardware).

J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/