[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |