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 AD65520958BC5 for ; Wed, 6 Sep 2017 03:17:55 -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 0482680F97; Wed, 6 Sep 2017 10:20:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0482680F97 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-41.rdu2.redhat.com [10.10.120.41]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8068780F9D; Wed, 6 Sep 2017 10:20:43 +0000 (UTC) To: "Wang, Jian J" , "Justen, Jordan L" , "Yao, Jiewen" Cc: "edk2-devel@lists.01.org" , "Kinney, Michael D" References: From: Laszlo Ersek Message-ID: <130779a4-f1c8-bf07-8b85-8125d466aed3@redhat.com> Date: Wed, 6 Sep 2017 12:20:42 +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]); Wed, 06 Sep 2017 10:20:45 +0000 (UTC) Subject: Re: ASSERT in QemuVideoDxe driver during reset 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: Wed, 06 Sep 2017 10:17:55 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 09/06/17 10:15, Wang, Jian J wrote: > Hi guys, > > I found an ASSERT issue in function InstallVbeShim() in QemuVideoDxe > driver during reset. The assert statement is like below. > > ASSERT (Int0x10->Segment == 0x0000); > ASSERT (Int0x10->Offset == 0x0000); > > This happened after I have enabled NULL pointer access detection > feature, in which page 0 (4K) is disabled. The NULL pointer access detection conflicts with the VBE shim. For installing the VBE shim, OVMF has to write to page 0, on purpose. Please see commit 90803342b1b6 ("OvmfPkg: QemuVideoDxe: Int10h stub for Windows 7 & 2008 (stdvga, QXL)", 2014-05-20). > And because of page 0 disabled, I have to skip the memory clearing for > page 0 in DXE core. By doing that, you invalidate the following comment in said OVMF commit: + // + // We managed to allocate the page at zero. SVN r14218 guarantees that it + // is NUL-filled. + // + ASSERT (Int0x10->Segment == 0x0000); + ASSERT (Int0x10->Offset == 0x0000); Because SVN r14218 was what added the clearing of page 0 to the DXE core. (Expressed as a git commit: d436d5ca0936.) > Otherwise it will cause page fault exception there. It seems that QEMU > may clear all its memory at startup. Skipping the action of clearing > page 0 in core won't cause ASSERT issue in QemuVideoDxe, for the first > time boot. But QemuVideoDxe will write int10 vector at memory 0x10 and > QEMU will not clear all its memory during warm boot. ASSERT will be > triggered after reset. QEMU does not clear guest RAM at reboot (or S3 resume). > It's easy to fix this issue but there're some subtle situations which > I'm not quite certain. I'd like your opinions for them. > > Here're my thoughts on several solutions: > a) Remove the ASSERT statement in InstallVbeShim(). Not a good idea. > But I'm sure if it is safe to do so because I don't quite understand > the purpose of the ASSERT. The ASSERT expresses our belief that, after we manage to *allocate* page 0, we can freely write the real mode Int0x10 vector there, without overwriting anything else. > b) Instead of skipping clearing page 0, enable it, do clearing and > then disable it. The problem here is that CPU arch protocol is not > ready at that time. I have to "manually" do page operation, which > might be non-portable and a little bit odd in DXE core. > c) Move code clearing page 0 from DXE core to another place wherever > appropriate, like DxeIpl or cpu driver. But I think there's a good > reason to put code there before. I'm not sure how the NULL pointer access detection is enabled. Is it enabled by a PCD? Hm, yes, it seems, from your patch [edk2] [PATCH 1/2] Implement NULL pointer detection for EDK-II Core that the PCD is called gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetection I can see in that patch that the DXE core is updated *not* to clear page 0 if the PCD is set to TRUE. That makes sense. However, OVMF should also be updated to skip the VBE shim installation if the PCD is set to TRUE. Namely, if the PCD is set to TRUE, then we simply cannot put the legacy Int0x10 vector in place, so we shouldn't even try. Please extend your original patch set with a patch for OvmfPkg. In the file "OvmfPkg/QemuVideoDxe/Driver.c", locate the InstallVbeShim() call site: > #if defined MDE_CPU_IA32 || defined MDE_CPU_X64 > if (Private->Variant == QEMU_VIDEO_BOCHS_MMIO || > Private->Variant == QEMU_VIDEO_BOCHS) { > InstallVbeShim (Card->Name, Private->GraphicsOutput.Mode->FrameBufferBase); > } > #endif and please skip the call if the PCD is set to TRUE: > #if defined MDE_CPU_IA32 || defined MDE_CPU_X64 > if (!FeaturePcdGet (PcdNullPointerDetection) && > (Private->Variant == QEMU_VIDEO_BOCHS_MMIO || > Private->Variant == QEMU_VIDEO_BOCHS)) { > InstallVbeShim (Card->Name, Private->GraphicsOutput.Mode->FrameBufferBase); > } > #endif Now, the consequence of this would be a working OVMF build, but it would also break booting UEFI Windows 7 on OVMF. Therefore, please append *another* patch to your patch set, setting the Feature PCD to FALSE in all three OVMF DSC files: - OvmfPkg/OvmfPkgIa32.dsc - OvmfPkg/OvmfPkgIa32X64.dsc - OvmfPkg/OvmfPkgX64.dsc We cannot break Windows 7 booting in upstream OVMF. If someone really wants the null pointer detection in OVMF (and doesn't need Windows 7 for sure), they can patch the DSC files, or else pass the --pcd=gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetection=TRUE option to the "build" utility. ... I'm now seeing in the original discussion that perhaps you will introduce a bitmap instead (one bit per firmware phase). That's OK with me; please reinterpret all of the above with the "DXE bit" then. When you post the next version of the patch set, please CC Jordan and myself on the OvmfPkg patches. Thank you! Laszlo