Re: [Xen-devel] Future x86 emulator direction

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 12/14/2016 09:14 AM, Jan Beulich wrote:
>>>> On 13.12.16 at 23:02, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel