Manuel Bouyer wrote:
On Thu, Aug 14, 2008 at 08:25:14PM +0200, Christoph Egger wrote:
Not really, as the write which is failing is also in dom0 (so on the
same
CPU). I think the tlb should be properly invalidated. Just to make sure
you can try adding
pmap_tlb_shootdown(pmap, va, 0, opte);
just after xpq_update_foreign() in pmap_enter_ma(). But as we're
switching pmaps on return to userland, this shouldn't be needed.
This has no impact.
As expected ... I'm running out of idea. I'll try to reproduce this
on my test box, but it won't be before next week.
I found the bug:
>>>>> - instrument privpgop_fault() to see if it gets called at all for
>>>>> this mapping, and if it's doing the right thing.
>>>>> There should be only one page in this object, and the machine
>>>>> address should be 0 (pobj->maddr[maddr_i])
>>>>>
>>>> Yes, privpgop_fault() is called. It looks like it's called in a
>>>> loop. npages = 1 and machine address is 0.
>>>>
>>> OK, it has the right data. I guess it's called in a loop because
>>> writing at the page keeps failing.
>>>
Writing at the page keeps failing because privpgop_fault()
does not handle this case:
if (pobj->maddr[maddr_i] == 0)
continue; /* this has already been flagged as error */
Removing this makes privpgop_fault() calling pmap_enter_ma()
and that makes the write access finally succeed and the HVM guest
starts.