On 21/04/2015 22:31, Laszlo Ersek wrote:
> typedef enum {
> EfiLockUninitialized = 0,
> EfiLockReleased = 1,
> EfiLockAcquired = 2
> } EFI_LOCK_STATE;
>
> typedef struct {
> EFI_TPL Tpl;
> EFI_TPL OwnerTpl;
> EFI_LOCK_STATE Lock;
> } EFI_LOCK;
>
> VOID
> EFIAPI
> EfiAcquireLock (
> IN EFI_LOCK *Lock
> )
> {
> ASSERT (Lock != NULL);
> ASSERT (Lock->Lock == EfiLockReleased);
>
> Lock->OwnerTpl = gBS->RaiseTPL (Lock->Tpl);
> Lock->Lock = EfiLockAcquired;
> }
>
> VOID
> EFIAPI
> EfiReleaseLock (
> IN EFI_LOCK *Lock
> )
> {
> EFI_TPL Tpl;
>
> ASSERT (Lock != NULL);
> ASSERT (Lock->Lock == EfiLockAcquired);
>
> Tpl = Lock->OwnerTpl;
>
> Lock->Lock = EfiLockReleased;
>
> gBS->RestoreTPL (Tpl);
> }
Okay, first of all this is obviously not a spinlock that works on a
multiprocessor system. But it is actually relatively close.
> But the prototypes of these functions are very misleading. They imply
> that you can take separate locks, and that locking one will not prevent
> locking another. This is false.
No, I think it can work. You just have to be aware of the TPL of the
locks. If you assume that you're being called with no lock taken, it's
easy to track that.
The TPL of the lock should be the highest TPL of "things that can
interrupt you". I guess you can just use TPL_NOTIFY and possibly then
look into relaxing it.
> Does SMI mask other interrupts "architecturally" perhaps?
It masks interrupts just because on entry to SMM the interrupt flag is
cleared. NMIs are also inhibited on entry to SMM.
> EFI_SMM_CONFIGURATION_PROTOCOL discussed in the "EDK II SMM Call
> Topology" document, on the "SmmDriverDispatcher" and especially the
> "SMBASE Relocation" pages. It takes a separate CPU driver, and
> (obviously) assembly code.
Oh, that's unfortunate. It's not really bad, as the SMM "trampoline"
code can be really small (SeaBIOS does just "mov %cs, %ax" followed by a
jump to its usual protected mode entry routine, IIRC) and the exit is
really as simple as "rsm". But it sucks. :(
Oh well, at least it's well documented.
Paolo
