Bug#676360: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
>>> Andrea Arcangeli <aarcange@redhat.com> 06/07/12 12:35 PM >>>
>Oops, sorry I didn't imagine atomic64_read on a pmd would trip.
The problem really is that the cmpxchg8b is a write, and hence won't go
through without faulting on a write protected page (which all page table
pages necessarily are).
>I guess if Xen can't be updated to handle an atomic64_read on a pmd in
>the guest, we can add a pmd_read paravirt op?
Xen could certainly be updated to treat cmpxchg8b on a PMD entry as a
simple 8-byte read when compared-to and to-be-stored values are
identical, but the problem would be that hypervisors in the field wouldn't
necessarily get updated.
>Or if we don't want to
>break the paravirt interface a loop like gup_fast with irq disabled
>should also work but looping + local_irq_disable()/enable() sounded
>worse and more complex than a atomic64_read (gup fast already disables
>irqs because it doesn't hold the mmap_sem so it's a different cost
>looping there). AFIK Xen disables THP during boot, so a check on THP
>being enabled and falling back in the THP=n version of
>pmd_read_atomic, would also be safe, but it's not so nice to do it
>with a runtime check.
That would probably nevertheless be the most viable option. If
performance critical(?), maybe this could be hidden with something
like the alternative instruction or paravirt patching mechanisms?
Jan
Reply to: