public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Leif Lindholm <leif.lindholm@linaro.org>
To: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	Laszlo Ersek <lersek@redhat.com>
Subject: Re: [PATCH] OvmfPkg/QemuVideoDxe: map framebuffer as write-combining/non-executable
Date: Fri, 18 Aug 2017 19:08:23 +0100	[thread overview]
Message-ID: <20170818180823.b24fsxtcy63zndq2@bivouac.eciton.net> (raw)
In-Reply-To: <150307857518.18247.16857169627688155787@jljusten-skl>

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


  reply	other threads:[~2017-08-18 18:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-18 13:02 [PATCH] OvmfPkg/QemuVideoDxe: map framebuffer as write-combining/non-executable Ard Biesheuvel
2017-08-18 13:04 ` Ard Biesheuvel
2017-08-18 17:20   ` Jordan Justen
2017-08-18 17:25     ` Ard Biesheuvel
2017-08-18 17:49       ` Jordan Justen
2017-08-18 18:08         ` Leif Lindholm [this message]
2017-08-18 19:36           ` Jordan Justen
2017-08-18 18:16         ` Ard Biesheuvel
2017-08-18 18:26 ` Leif Lindholm
2017-08-18 21:42 ` Laszlo Ersek
2017-08-18 21:51   ` Ard Biesheuvel
2017-08-22 14:31     ` Ard Biesheuvel
2017-08-22 15:44       ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170818180823.b24fsxtcy63zndq2@bivouac.eciton.net \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox