From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkfFs-0004D7-BM for qemu-devel@nongnu.org; Tue, 21 Apr 2015 16:58:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkfFn-0003h2-8S for qemu-devel@nongnu.org; Tue, 21 Apr 2015 16:58:52 -0400 Received: from mail-wg0-x236.google.com ([2a00:1450:400c:c00::236]:33306) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkfFn-0003gx-18 for qemu-devel@nongnu.org; Tue, 21 Apr 2015 16:58:47 -0400 Received: by wgin8 with SMTP id n8so226223473wgi.0 for ; Tue, 21 Apr 2015 13:58:46 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5536BA01.7060602@redhat.com> Date: Tue, 21 Apr 2015 22:58:41 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1429521560-2743-1-git-send-email-kraxel@redhat.com> <1429521560-2743-6-git-send-email-kraxel@redhat.com> <55365F05.1050402@redhat.com> <553660EC.4040902@redhat.com> <5536672A.6060809@redhat.com> <55366ADF.4000707@redhat.com> <5536B3A8.8040008@redhat.com> In-Reply-To: <5536B3A8.8040008@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek , Gerd Hoffmann Cc: edk2-devel list , qemu-devel@nongnu.org, mst@redhat.com 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