On 5/12/07 17:17, Derek Murray [EMAIL PROTECTED] wrote:
Actually I'm not so sure now. Presumably you add VM_PFNMAP to make
vm_normal_page() return NULL? But actually I would expect pte_pfn() to
return max_mapnr because the mapped page is not a local page. And that
should cause
On 5/12/07 20:15, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
In 2.6.18-xen the only two implementations of zap_pte are
blktap_clear_pte and gntdev_clear_pte. Given a ptep with the
grant-mapping bit set, could we determine which of these need calling
and do the appropriate thing? Do we
On 5/12/07 14:30, Derek Murray [EMAIL PROTECTED] wrote:
Keir Fraser wrote:
Is this patch to go into linux-2.6.18-xen.hg then?
Yes, even if it doesn't fix the exact bug we're seeing here, I think it
should go in. I've attached a version with my signed-off-by and a better
commit comment
On 6/6/07 12:00, Jan Beulich [EMAIL PROTECTED] wrote:
If the error across CPUS is +/- just a few microseconds at worst then having
the clocksource clamp to no less than the last timestamp returned seems a
reasonable fix. Time won't 'stop' for longer than the cross-CPU error, and
that
On 27/4/07 08:08, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Don't you need a rmb() here then? The CPU could speculate reads
(more occurrences)
Is rmb() sufficient? It will stop a speculative read on the pending
flag, but will it make sure the write has happened by then? Ie, is it a
