Re: [Xen-devel] Re: [PATCH] xen: remove support for non-PAE 32-bit

[Robert Kaiser (FH)]

Am Dienstag 13 Mai 2008 13:48 schrieb Jeremy Fitzhardinge:
> Robert Kaiser (FH) wrote:
> > Hmm, I had to revert to non-PAE operation (using xen 3.2.1) recently in
> > order to get Xen to run under qemu. Does anyone know of another
> > work-around to run Xen/Linux under qemu?
>
> In principle it should work in PAE mode;

I thought so, too, however it doesn't :-(.

> it certainly works in kvm. 
> What problem are you seeing?

Linux crashes just after the message "Freeing unused 
kernel memory: ..." due to dereferencing a bad address.

The following is from the top of my head (if you need more details, let me kow 
and I'll recompile everything with PAE so I can reproduce the problem again 
-- this will take some time though..):

The crash results from a call to do_munmap(). Strangely though, when setting a 
breakpoint at the faulting assembly instruction (I'm using qemu's debug stub 
facility) , the problem disappears: the address being dereferenced (contained 
in register eax) is always a valid one. However, as soon as I remove that 
breakpoint and hit "continue", it does crash again with the crash dump 
showing an eip pointing to where the breakpoint formerly was, and an invalid 
address in eax.

> I think there's a bug in qemu's x86 
> emulation with respect to mis-reporting the eip of an xchg which faults,
> which may be what you're seeing.

The eip that was reported was always the same, and there was no xchg 
instruction at that address. It might have been consistently wrong though 
(how would I figure this out?).


Rob

-- 
Robert Kaiser                    http://wwwvs.informatik.fh-wiesbaden.de
Labor für Verteilte Systeme            kaiser@xxxxxxxxxxxxxxxxxxxxxxxxxx
FH Wiesbaden - University of Applied Sciences     tel: (+49)611-9495-294
Kurt-Schumacher-Ring 18, 65197 Wiesbaden, Germany fax: (+49)611-9495-294
--
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/