On 18 August 2017 at 11:23, Alex Bennée <alex.ben...@linaro.org> wrote: > Peter Maydell <peter.mayd...@linaro.org> writes: >> On 18 August 2017 at 09:40, Alex Bennée <alex.ben...@linaro.org> 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