On 18 September 2013 22:11, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 18/09/2013 13:56, Peter Maydell ha scritto: >>> > But does guest code actually care? In many cases, I suspect that >>> > sticking a smp_rmb() in the read side of "unlocked" register accesses, >>> > and a smp_wmb() in the write side, will do just fine. And add a >>> > compatibility property to place a device back under the BQL for guests >>> > that have problems. >> Yuck. This sounds like a recipe for spending the next five years >> debugging subtle race conditions. We need to continue to support >> the semantics that the architecture and hardware specs define >> for memory access orderings to emulated devices. > > We cannot in the general case, QEMU is not a cycle-exact simulator.
This isn't a cycle-accuracy issue (unsurprisingly, since bus specs and architecture barrier definitions are written to work with multiple implementations of the same CPU). > There's nothing magic, really. Both PV and real devices have been doing > it forever by placing some registers in RAM instead of MMIO, and > communicating synchronization points via interrupts and doorbell registers. Sure, but that's a hardware design choice, it's different from ripping out the assumptions about device behaviour from underneath an existing driver. -- PMM