>>> Razvan Cojocaru <rcojoc...@bitdefender.com> 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. Jan >(From the Intel SDM) "Causes the processor’s LOCK# signal to be asserted >during execution of the accompanying instruction (turns the instruction >into an atomic instruction). In a multiprocessor environment, the LOCK# >signal ensures that the processor has exclusive use of any shared memory >while the signal is asserted." > >Using a spin lock (or the rwlock in the manner described above) in >hvmemul_cmpxchg() only prevents two LOCKed instructions from running at >the same time, but presumably even non-LOCKed instructions just reading >that memory area should be prevented from running until the LOCKed >instruction is done (hence the guest starting up with the rwlock in >x86_emulate() but not with it locked only in hvmemul_cmpxchg()). > >Hopefully I haven't misunderstood the issue. > > >Thanks, >Razvan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
