Re: [Qemu-devel] [Bug 1706296] Re: Booting NT 4 disk causes /home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked())

[Peter Maydell]

On 18 August 2017 at 11:23, Alex Bennée <address@hidden> wrote:
> Peter Maydell <address@hidden> writes:
>> On 18 August 2017 at 09:40, Alex Bennée <address@hidden> wrote:
>>> It might be related. The assertion error is caused by the fact an
>>> exception has occurred and processor is trying to dump a stack frame that
>>> overlaps from RAM into device memory. As the IRQ/exception handling is
>>> already under the BQL (as it changes machine state) we get the assertion
>>> when it tries to take the BQL a second time when accessing device
>>> memory.
>>
>> This sounds worrying -- lots and lots of target backend code
>> does writes to memory. Is it all going to cause assertions if
>> it happens to be pointing at a device?
>
> Currently yes.
>
> That said from John's update it sounds very much like a symptom of not
> emulating the right processor type rather than behaviour we are
> incorrectly modelling. If we invert the lock before writing the stack
> page is it just going to crash in a more esoteric way?
>
> I'm not sure how you correctly emulate writing random stack pages to a
> random device. Unless there is some sort of weird [un]documented behaviour
> we should be doing?

The desired behaviour is straightforward -- if the code calls
a function for "do a 4 byte write" then we do a 4 byte write
to the device. The only place where writing to a device has
to be special cased is when we're trying to execute code
from it (which is itself arguably a defect of our emulation).

It looks like we only get this double locking when the
target/ code does a write-by-virtual-address (which ends
up going via io_writex() which takes the lock again) --
write-by-physical-address, eg stl_phys and friends presumably
don't take the lock. That's a rather confusing mismatch of
semantics.

thanks
-- PMM