Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Andrea Arcangeli <aarcange@xxxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel