From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 069AD2095BB66 for ; Tue, 5 Sep 2017 15:34:58 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B8A5F745B5; Tue, 5 Sep 2017 22:37:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B8A5F745B5 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-185.rdu2.redhat.com [10.10.120.185]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4327F6E700; Tue, 5 Sep 2017 22:37:45 +0000 (UTC) To: Ard Biesheuvel Cc: Tom Lendacky , Jordan Justen , "edk2-devel@lists.01.org" , Jiewen Yao , Star Zeng References: <1504265045-19008-1-git-send-email-brijesh.singh@amd.com> <1504265045-19008-2-git-send-email-brijesh.singh@amd.com> <04fefb16-23d5-f6df-0657-9d4c5e96ac57@redhat.com> <4f286363-6f04-bee0-8b12-34b50a813e70@amd.com> <5992734a-1ded-9d4b-36bd-99c13f30ca32@redhat.com> From: Laszlo Ersek Message-ID: <0edadd86-44aa-9c65-eb3a-be801e8ec1eb@redhat.com> Date: Wed, 6 Sep 2017 00:37:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 05 Sep 2017 22:37:46 +0000 (UTC) Subject: Re: [PATCH 1/5] OvmfPkg/VirtioNetDxe: map VRING using VirtioRingMap() X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 22:34:58 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 09/06/17 00:18, Ard Biesheuvel wrote: > On 5 September 2017 at 22:59, Laszlo Ersek wrote: >> On 09/05/17 23:11, Ard Biesheuvel wrote: >>> (which means it could be the second time it was called). >> >> Side remark: the CoreExitBootServices() implementation does not notice >> memory map changes incurred by the ExitBootServices() handlers, in my >> interpretation. >> >> CoreExitBootServices() has a MapKey (= "memmap generation") check early >> on, in CoreTerminateMemoryMap(). This check catches memmap changes >> between the last GetMemoryMap(), and the call to ExitBootServices(). >> >> After this check succeeds, the notify functions are kicked, and on this >> path, CoreExitBootServices() simply cannot return any other value than >> EFI_SUCCESS. So whatever mess the individual callbacks make, it doesn't >> notice or report. >> > > CoreExitBootServices() disables the timer first, and so it will return > with event dispatch disabled if it fails, ensuring that it is no > longer possible for an event handler to be invoked between > GetMemoryMap and ExitBootServices. True, but that's not what I meant -- I meant that, if an EBS handler violates its contract and changes the memory map (= "it makes mess"), on the call stack of CoreNotifySignalList (&gEfiEventExitBootServicesGuid); then CoreExitBootServices() won't notice it, it won't return an error, and the caller of EBS() won't go back to calling GetMemoryMap() again. > Indeed. I think it is justified to treat the IOMMU protocol specially. The MemoryProtectionExitBootServicesCallback() function call looks like prior art for such customizations. This would mean more delay for SEV, but it would be a very desirable cleanup, for the long term! Thanks! Laszlo