On 12/14/2016 09:14 AM, Jan Beulich wrote: >>>> On 13.12.16 at 23:02, <andrew.coop...@citrix.com> wrote: >> On 13/12/2016 21:55, Razvan Cojocaru wrote: >>> On a somewhat related note, it's important to also figure out how best >>> to avoid emulation races such as the LOCK CMPXCHG issue we've discussed >>> in the past. Maybe that's also worth taking into consideration at this >>> early stage. >> >> Funny you should ask that. >> >> The only possible way to do this safely is to have the emulator map the >> target frame(s) and execute a locked stub instruction with a memory >> operand pointing at the mapping. We have no other way of interacting >> with the cache coherency fabric. > > Well, that approach is necessary only if one path (vCPU) can write > to a page, while another one needs emulation. If pages are globally > write-protected, an approach following the model from Razvan's > earlier patch (which I have no idea what has become of) would > seem to suffice.
As previously stated, you've raised performance concerns which seemed to require a different direction, namely the one Andrew is now suggesting, which indeed, aside from being somewhat faster is also safer for all cases (including the one you've mentioned, where one path can write normally and the other does so via emulation). The old patch itself is still alive in the XenServer patch queue, albeit quite unlikely to be trivial to apply to the current Xen 4.9-unstable code in its current form: https://github.com/xenserver/xen-4.7.pg/blob/master/master/xen-x86-emulate-syncrhonise-LOCKed-instruction-emulation.patch Again, if you decide that this patch is preferable, I can try to rework it for the current version of Xen. Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
