Hi,

On Wed, Nov 28, 2007 at 02:49:17PM +0100, Christoph Egger wrote:
> 
> Hi Manuel!
> 
> I just noticed your xenkernel3 package update:
> 
> RCS file: /cvsroot/pkgsrc/sysutils/xenkernel3/patches/patch-ba,v
> Working file: patch-ba
> head: 1.2
> branch:
> locks: strict
> access list:
> symbolic names:
>         pkgsrc-2007Q3: 1.1.0.2
>         pkgsrc-2007Q3-base: 1.1
> keyword substitution: kv
> total revisions: 2;     selected revisions: 2
> description:
> ----------------------------
> revision 1.2
> date: 2007/11/26 19:35:25;  author: bouyer;  state: Exp;  lines: +12 -3
> Properly initialize physaddr_bitsize for native 64bit dom0. Makes
> NetBSD/xenamd64 boot on systems with more than 4Gb RAM.
> Bump pkgrevision.
> 
> 
> Looking at the diff, you unconditionally initialize d->arch.physaddr_bitsize.
> Are you sure this is correct for 32bit / 32bit pae Dom0 ?
> 
> Further, for 64bit xen-kernels this is already initialized some lines further 
> below and overrides your hardcoded value. So I don't understand in which
> way your patch fixes the boot problem with more than 4GB RAM.
> 
> Can you explain this, please?

I tracked down my problem with more than 4GB RAM to d->arch.physaddr_bitsize
being 0 in domain_clamp_alloc_bitsize(). This cause all attemps to
XENMEM_increase_reservation with bits > 0 to fail (well for bits == 32
at last, maybe this test is short-circuited for other values of bits).

In construct_dom0(), physaddr_bitsize is initialised only if
ifdef CONFIG_COMPAT and if elf_32bit(&elf) (which, I assume, means that
dom0 is a 32bit kernel) and if UNSET_ADDR != parms.virt_hv_start_low
(I didn't look at what this could mean).

So, if I got it right, my patch should cause physaddr_bitsize to be 64 by
default, and set to some other value later if needed; and if "not needed" 64
is the right value. If the hypervisor is not 64bits, physaddr_bitsize isn't
used at all anyway.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--