On 2017-08-18 10:25:14, Ard Biesheuvel wrote: > On 18 August 2017 at 18:20, Jordan Justen <[email protected]> wrote: > > On 2017-08-18 06:04:01, Ard Biesheuvel wrote: > >> On 18 August 2017 at 14:02, Ard Biesheuvel <[email protected]> > >> 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 regions, > >> > 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_CONSUMED > > > > 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
