Re: uvm_fault with -current XEN3_DOMU

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

On Friday 16 May 2008 15:19:00 Manuel Bouyer wrote:
> On Fri, May 16, 2008 at 02:01:25PM +0200, Christoph Egger wrote:
> > On Friday 16 May 2008 12:53:49 Manuel Bouyer wrote:
> > > On Fri, May 16, 2008 at 11:39:32AM +0200, Christoph Egger wrote:
> > > > On Thursday 15 May 2008 10:18:15 Manuel Bouyer wrote:
> > > > > On Thu, May 15, 2008 at 11:45:54AM +1200, Mark Davies wrote:
> > > > > > Trying to run an i386 XEN3_DOMU kernel from this morning results
> > > > > > in an immediate uvm_fault:
> > > > > >
> > > > > > green-mountain# xm create -c homepages
> > > > > > Using config file "/etc/xen/homepages".
> > > > > > Started domain homepages
> > > > > >  MAC address 00:16:3e:00:00:11
> > > > > > unknown type console at xenbus0 id 0 not configured
> > > > > > uvm_fault(0xc04b1d00, 0, 1) -> 0xe
> > > > > > kernel: supervisor trap page fault, code=0
> > > > > > Stopped in pid 0.2 (system) at  0:      invalid address
> > > > > > db> bt
> > > > > > uvm_fault(0xc04b1d00, 0, 1) -> 0xe
> > > > > > kernel: supervisor trap page fault, code=0
> > > > > > Faulted in DDB; continuing...
> > > > > > db>
> > > > >
> > > > > I've seen this too. It's probably calling a NULL function pointer.
> > > > > I've not had a chance to look at this more closely yet.
> > > > >
> > > > >From a rough look into this, this seems to be an interrupt problem.
> > > >
> > > > The problem is not DomU specific. It also happens on Dom0 -current.
> > >
> > > in my case it seems to be because:
> > > db> x/x x86_cpu_idle
> > > netbsd:x86_cpu_idle:    0
> >
> > On Dom0, I didn't have the chance to get into ddb as I got into an
> > endless loop of faults in ddb.
> >
> > > The attached patch makes a domU kernel boot for me again. I'll commit
> > > it this evening unless somone beats me.
> >
> > I can confirm this makes dom0 boot again - with an workaround:
> > cpu_identify(ci) works for the cpu but not the vcpu.
> > the cpu identify code thinks, the vcpu is a 386 CPU and calls
> > panic in x86/x86/identcpu.c, line 816.
>
> It seems to work for me on a i386PAE domU:
>
> vcpu0 at hypervisor0: (uniprocessor)
>
> : Intel 686-class, 2327MHz, id 0x6fb
>
> vcpu0: 64 page colors
>
> Will try a amd64 domU ...

DomU doesn't need the workaround. DomU is fine. The trouble comes
from the cpu/vcpu split in the Dom0.

Christoph