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

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

Nakajima, Jun wrote:
> > > 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)
>   
Hm, this is (I guess) intending to map machine physical memory.  If it 
doesn't have _PAGE_IOMAP set in the pte, then we'll try to do a pfn->mfn 
conversion, which won't work well if the pte doesn't have a pfn to start 
with.
I've just been trying to get drm doing something sensible, so I've made 
some fixes in this area.  Have a look at today's lot of xen/dom0/hackery 
changesets.
> > > 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).
>   
Keir, do you know anything about this?  It seems that multicalls are not 
reliably reporting errors.
   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel