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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 04.05.16 at 13:32, <rcojocaru@bitdefender.com> wrote:
> But while implementing a stub that falls back to the actual LOCK CMPXCHG
> and replacing hvm_copy_to_guest_virt() with it would indeed be an
> improvement (with the added advantage of being able to treat
> non-emulated LOCK CMPXCHG cases), I don't understand how that would
> solve the read-modify-write atomicity problem.
> 
> AFAICT, this would only solve the write problem. Assuming we have VCPU1
> and VCPU2 emulating a LOCKed instruction expecting rmw atomicity, the
> stub alone would not prevent this:
> 
> VCPU1: read, modify
> VCPU2: read, modify, write
> VCPU1: write

I'm not sure I follow what you mean here: Does the above represent
what the guest does, or what the hypervisor does as steps to emulate
a _single_ guest instruction? In the former case, I don't see what
you're after. And in the latter case I don't understand why you think
using CMPXCHG instead of WRITE wouldn't help.

Jan

> Moreover, since reads and writes are not synchronized, it would be
> possible for VCPU2's read to occur while VCPU1 writes, and VCPU1 could
> read part of the old data + part of the new data.
> 
> So the problem originally addressed by the patch would still need to be
> addressed like that: with a read / write lock covering all the relevant
> parts of x86_emulate(). Unless I'm mistaken, the stub part is only
> needed to make sure that CMPXCHG alone does not race when a VCPU
> emulates and another does not.
> 
> 
> Thanks,
> Razvan




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