Re: Tracebacks from dom0 pvops changeset 2342

[Jeremy Fitzhardinge <jeremy@goop.org>]

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