RE: [Xen-devel] Tracebacks from dom0 pvops changeset 2342

["Nakajima, Jun" <jun.nakajima@xxxxxxxxx>]

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