qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 00/38] Delay destruction of memory regions to


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2 00/38] Delay destruction of memory regions to instance_finalize
Date: Wed, 18 Sep 2013 22:19:07 +0900

On 18 September 2013 22:11, Paolo Bonzini <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]