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:33, Peter Maydell <address@hidden> wrote:
> 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.

Hi Alex -- do we have a fix for this assertion now, or is it still
on your todo list?

thanks
-- PMM