Re: [PATCH] OvmfPkg/QemuVideoDxe: map framebuffer as write-combining/non-executable

[Leif Lindholm <leif.lindholm@linaro.org>]

On Fri, Aug 18, 2017 at 10:49:35AM -0700, Jordan Justen wrote:
> On 2017-08-18 10:25:14, Ard Biesheuvel wrote:
> > On 18 August 2017 at 18:20, Jordan Justen <jordan.l.justen@intel.com> wrote:
> > > On 2017-08-18 06:04:01, Ard Biesheuvel wrote:
> > >> On 18 August 2017 at 14:02, Ard Biesheuvel <ard.biesheuvel@linaro.org> 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*?

Not immediately, no.

Conversely, does IA32/X64 WC not guarantee writing out within a finite period?

/
    Leif

> 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