[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Future x86 emulator direction



>>> 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.

> I think the shadow cmpxchg() hook is nearly there, although the
> implementation does need to up into the body of the emulator along with
> a map()/unmap() pair of primitives.

To be honest, I don't think we should have map/unmap primitives.
Instead the cmpxchg() hook needs to be told enough to properly
do its job.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.