On Wed, Apr 05, 2017 at 06:28:06PM +0200, Ralf Ramsauer wrote:
> On 04/05/2017 03:46 PM, Mark Rutland wrote:
> > On Wed, Apr 05, 2017 at 12:38:05PM +0200, Ralf Ramsauer wrote:
> >> 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?
> Inmate memory starts at guest physical zero, so that should be no
> problem.
Ok; that rules out a number of potential issues.
> This assembly snippet is not meant to do anything useful, I
> just tried to trace down why spinlocks aren't working and this is the
> instruction that seems to (reproducibly) cause the misbehavior.
Sure thing.
> I tried the same code on a Orange Pi zero together with Jailhouse and
> experienced different behavior: It only prints "Foo!" and stops then.
> And I'm able to destroy the cell as expected.
> >
> > Is the MMU on? Architecturally, ldrex/strex are only guaranteed to
> From the guest's point of view, the MMU is turned off.
Ok. That means that the ldrex is UNPREDICTABLE, per ARM DDI 0406C.c,
A3.4.2 ("Exclusive access instructions and Shareable memory regions").
... though that doesn't explain what specifically is going on here.
> > 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?
> Yep, I do, on the TK1.
>
> On the Orange Pi 0, behavior does not change: I only see "Foo!" in
> either case.
It *might* be the case that on Orange Pi, the ldrex generates a PL1
exception that the guest doesn't handle, leaving it stuck in the
exception handlers.
I do not have a good explanation for what's going on with the TK1. If
the ldrex generates some unhandled PL2 exception, that could explain the
inability to kill it, and the system-wide hang, but I don't see how the
second print could occur in that case, unless the exception were
asynchronous.
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.
