On Tuesday 10 March 2009 16:30:13 Jean-Yves Migeon wrote:
Christoph Egger wrote:
> PFN 55555 is obviously bogus. It gets used as poison in
machine-to-phys and
> phys-to-machine tables in some cases. domain->interface should have been
> mapped at setup time by a call to xc_map_foreign_range() in
> xenstored_domain.c:do_introduce(). An attempt to demand-map the
> interface page probably means something went wrong earlier.
Hmm, if this problem happens while there is no domain running (except
dom0), I am not sure that the xc_map_foreign_range() code is at fault.
I am more inclined to say that the mmap() code used to map the initial
xen_start_info of dom0 (through /dev/xsd_kva) is doing something wrong
(see dom0_init() with the call to xenbus_map()). This part is skipped
when you start xenstored with -D, which looks plausible to me.
However, I can't manage to reproduce that issue with dom0 PAE and Xen3.3.
Reading xsd_kva code around its mmap routine (xenevtmmap() in
arch/xen/xen/xenevt.c), it is using x86_btop which casts away to
unsigned long, which could be wrong with PAE (paddr_t being unsigned
long long).
Could you give [1] a try (ugly, but I'd like to check that first)
Thanks,
[1] http://www.netbsd.org/~jym/xenevt.c.diff
The output with this patch is:
store_mfn: MFN 1050807 PFN 1431654400
store_mfn: MFN 1050807 PFN 1431654400
(XEN) mm.c:1784:d0 Error pfn 55555: rd=ff2b4100, od=00000000, caf=00000000,
taf=00000000
(XEN) mm.c:712:d0 Error getting mfn 55555 (pfn 55555555) from L1 entry
0000000055555067 for dom0
xpq_flush_queue: 1 entries
0x000000010211d608: 0x0000000055555067
panic: HYPERVISOR_mmu_update failed