On Thu, Aug 14, 2008 at 07:10:25PM +0200, Christoph Egger wrote:
On Thursday 14 August 2008 19:05:08 Manuel Bouyer wrote:
On Thu, Aug 14, 2008 at 06:57:15PM +0200, Christoph Egger wrote:
OK, so 0x9c1ff167 is really the complete pte value. This would make it
point to a physical address at 2497MB. Do you have that much memory in
this box ?
Yes. It has 4GB.
OK, so we have a valid pte entry, pointing to valid memory, for the
affected VA; yet writing to the VA seems to cause a fault. The only
remaining issue I can see is that we would be updating the wrong pmap.
but I can't see how it could happen for this case, and not for the
other IOCTL_PRIVCMD_MMAP users ...
The machine is a Dual-Core CPU machine. Since NetBSD/Xen (= Dom0)
utilizes only the BSP due to lack of SMP support, it is very likely the
guest utilizes the other CPU core.
Does this help?
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.