On Wed, Apr 05, 2017 at 12:38:05PM +0200, Ralf Ramsauer wrote:
> Hi,
Hi,
> I need spinlocks in inmates on ARM, so I simply included asm/spinlock.h.
> Taking locks in inmates on ARM somehow doesn't work at all, but that's
> not the main issue. As soon as I try to take locks, cells can not be
> destroyed any longer, the whole system freezes on cell destroy.
>
> I was able to trace this down to the 'ldrex' instruction. This minimal
> example triggers this behavior (tested on a TK1, can not test it on
> other boards):
>
> #include <inmate.h>
>
> void inmate_main(void)
> {
> unsigned int foo = 0, bar = 0;
>
> printk("Foo!\n");
> asm volatile("ldrex %0, [%1]\n\t"
> : "=&r" (foo) : "r" (bar));
That looks busted. The second parameter is the value of bar, not the
address of bar, so we'll dereference NULL. Either that should be &bar,
or a "Q" constraint should be used ("+Q" if you had a strex).
What's the memory map of the inmate? Could that result in a
(destructive) read from device memory? Or some asynchronous abort?
Is the MMU on? Architecturally, ldrex/strex are only guaranteed to
function on write-back cacheable memory, and I can't recall the
permitted UNPREDICTABLE behaviours otherwise.
>
> printk("Bar!\n");
> while(1);
> asm volatile("wfi");
> }
>
>
> The example code successfully finishes, I can read Foo and Bar on my
> serial console. But I am not able to destroy the cell afterwards. My
> system completely hangs on "jailhouse cell destroy".
What happens if you place a full-system DSB between the printks and hte
ldrex, i.e.
asm volatible ("dsb sy\n" ::: "memory");
... do you still see the "Bar!" print?
>
> Curiously the cell can be re-loaded and started over again. Leaving out
> the ldrex instruction does not trigger the bug.
>
> - How can ldrex prevent my cell from being destroyed?
>
> Does it change some 'internal state' where jailhouse is not aware
> about?
>
> - Why do spinlocks not work at all in inmates?
>
> spin_lock(&lock) never returns in inmates on a fresh spin lock.
> Does the ARM implementation of spinlocks require some special
> global initialisation that I don't know of?
The only thing I can think of is that the location being operated upon
should be in write-back cacheable memory (with shareability common to
all agents that may access the region).
Thanks,
Mark.
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
