On 2/9/2009 5:16:48 PM, Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > BTW, I tried 2350 (latest), and I'm seeing repeated complaints from
> > mod_l1_entry(). (XEN) mm.c:1650:d0 Bad L1 flags 400000
> >
>
> Is this 32 or 64 bit? I fixed similar symptoms in 32-bit with
> "x86/paravirt: return full 64-bit result" I think.
64-bit.
>
> > By adding printk, I got the same info: mfn=ff7fffffff, gl1mfn=72c96
> > from every complaint; mfn looks bogus.
> >
>
> Sure does.
>
> > Looks like it's the mod_l1_entry() called by do_update_va_mapping(),
> > and the guest stack shows (by vcpu_show_execution_state() that I
> > added) it's going back to xen_mc_flush(). As long as I ignore the
> > MEM_LOG message, it boots up to the login prompt.
> >
>
> Odd. What's the backtrace beyond that?
This is coming from remap_pte_range() in dom0, which calls set_pte_at(),
calling MULTI_update_va_mapping(). Looks like pteval is 0xfffff7fffffff237. As
far as I checked the code, the prot has the NX bit :-), and pfn looked normal
there:
pte_mkspecial(pfn_pte(pfn, prot)
The pfn_pte() eventually calls xen_make_pte(), and pte_pfn_to_mfn() looks
suspicious (>> PAGE_SHIFT when the bit 63 is set):
static pteval_t pte_pfn_to_mfn(pteval_t val)
{
if (val & _PAGE_PRESENT) {
unsigned long pfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
pteval_t flags = val & PTE_FLAGS_MASK;
val = ((pteval_t)pfn_to_mfn(pfn) << PAGE_SHIFT) | flags;
}
return val;
}
pte_t xen_make_pte(pteval_t pte)
{
phys_addr_t addr = (pte & PTE_PFN_MASK);
/*
* Unprivileged domains are allowed to do IOMAPpings for
* PCI passthrough, but not map ISA space. The ISA
* mappings are just dummy local mappings to keep other
* parts of the kernel happy.
*/
if (unlikely(pte & _PAGE_IOMAP) &&
(xen_initial_domain() || addr >= ISA_END_ADDRESS)) {
pte = iomap_pte(pte);
} else {
pte &= ~_PAGE_IOMAP;
pte = pte_pfn_to_mfn(pte);
}
return native_make_pte(pte);
}
I'll take a closer look tomorrow.
>
> > One thing that puzzles me is that MC_DEBUG is 1 in multicalls.c, but
> > I don't see any complaints from dom0. Is the following MC_DEBUG working?
> > Or I may be looking at a wrong stack.
> >
>
> Yes, I've noticed that sometimes multicalls seem not to report
> detectable errors. I haven't looked into see what's really going on.
>
> J
I confirmed that the multicalls were failing in Xen (but the result was not
propagated to the caller).
.
Jun Nakajima | Intel Open Source Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home