From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 D42B82095E01A for ; Fri, 18 Aug 2017 10:47:07 -0700 (PDT) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2017 10:49:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,393,1498546800"; d="scan'208";a="120474959" Received: from pcastin-mobl1.amr.corp.intel.com (HELO localhost) ([10.254.176.77]) by orsmga004.jf.intel.com with ESMTP; 18 Aug 2017 10:49:35 -0700 MIME-Version: 1.0 To: Ard Biesheuvel Message-ID: <150307857518.18247.16857169627688155787@jljusten-skl> From: Jordan Justen In-Reply-To: Cc: "edk2-devel@lists.01.org" , Laszlo Ersek , Leif Lindholm References: <20170818130243.4645-1-ard.biesheuvel@linaro.org> <150307684325.17751.1587324408306927566@jljusten-skl> User-Agent: alot/0.6.0dev Date: Fri, 18 Aug 2017 10:49:35 -0700 Subject: Re: [PATCH] OvmfPkg/QemuVideoDxe: map framebuffer as write-combining/non-executable 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: Fri, 18 Aug 2017 17:47:08 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2017-08-18 10:25:14, Ard Biesheuvel wrote: > On 18 August 2017 at 18:20, Jordan Justen wro= te: > > On 2017-08-18 06:04:01, Ard Biesheuvel wrote: > >> On 18 August 2017 at 14:02, Ard Biesheuvel = wrote: > >> > When QemuVideoDxe takes control of the framebuffer, it is already > >> > mapped EFI_MEMORY_UC by core code, and QemuVideoDxe simply records > >> > the base and size from the PCI BAR. > >> > > >> > On x86 systems, this is sufficient, but on ARM systems, the semantics > >> > of EFI_MEMORY_UC regions are quite different from EFI_MEMORY_WC regi= ons, > >> > and treating a region like memory (i.e., dereferencing pointers into= it > >> > or using ordinary CopyMem()/SetMem() functions on it) requires that = it > >> > be mapped with memory semantics, i.e., EFI_MEMORY_WC, EFI_MEMORY_WT = or > >> > EFI_MEMORY_WB. > >> > > >> > Since caching is not appropriate for regions where we rely on side > >> > effects, remap the frame buffer EFI_MEMORY_WT. > >> > >> EFI_MEMORY_WC not WT > > > > If a single pixel is written, then WC may not write it through > > immediately. Would WT be more appropriate? > > > = > For ARM, that applies equally to WT AFAIK. Write-through will not actually write-*through*? I'm not sure how well QEMU/KVM models this for x86 or ARM. > >> > > >> > [Protocols] > >> > + gEfiCpuArchProtocolGuid # PROTOCOL ALWAYS_C= ONSUMED > > > > I don't think a 'Driver Model' driver needs to add arch protocols into > > the depex. > > > = > To be pedantic: this is not the depex. You can't rely on the protocol > header to declare gEfiCpuArchProtocolGuid, and declaring it here makes > the build tools add its declaration to AutoGen.h (I think this has to > do with the exact .dsc version. Perhaps Laszlo has a better > recollection of the details.) Whoops. You are correct. We want this change... -Jordan