Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 26/04/16 18:23, Razvan Cojocaru wrote:
> On 04/26/16 19:03, George Dunlap wrote:
>> On 19/04/16 17:35, Jan Beulich wrote:
>>>>>> Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> 04/19/16 1:01 PM >>>
>>>> I think this might be because the LOCK prefix should guarantee that the
>>>> instruction that follows it has exclusive use of shared memory (for both
>>>> reads and writes) but I might be misreading the docs:
>>> LOCK definitely has no effect on other than the instruction it gets applied
>>> to.
>> Sorry I wasn't involved in this discussion -- what was the conclusion here?
>>
>> FWIW Andy's suggestion of using a stub seemed like the most robust
>> solution, if that could be made to work.
>>
>> If you're going to submit a patch substantially similar to this one, let
>> me know so I can review the mm bits of the original patch.
> I'm not really sure.
>
> Regarding this version of the patch, Jan has asked for more information
> on the performance impact, but I'm not sure how to obtain it in a
> rigorous manner. If it is decided that a version of this patch is
> desirable, I can go on fixing the issues we've found and address the
> comments we've had so far and submit a new version.

XenServer did performance testing.  No observable impact for normal VM
workloads (which is to be expected, as an OS wouldn't normally LOCK the
instructions it uses for MMIO).  The per-cpu rwlocks have ~0 overhead
when the lock isn't held for writing.

>
> I'm not familiar with what the stub solution would imply, so I'm afraid
> I can't comment on that. This is not code I've had that much contact
> with prior to stumbling into this problem.

As for the fix I suggested, its probably prohibitive to fix the current
emulator, given the plans for a rewrite.  (And on that note, I really
need to write a design doc and post to the list).

~Andrew

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