qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger()


From: Paolo Bonzini
Subject: Re: [Qemu-devel] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger()
Date: Tue, 21 Apr 2015 22:58:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]