public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: edk2-devel@lists.01.org
Subject: Re: [PATCH v3 2/4] OvmfPkg: add QemuRamfbDxe
Date: Wed, 13 Jun 2018 21:15:06 +0200	[thread overview]
Message-ID: <de71366e-e237-7f31-cc47-2ff705e5bcf7@redhat.com> (raw)
In-Reply-To: <a4a14a8b-5181-f9e3-1cb8-0136472dbbd6@redhat.com>

On 06/13/18 21:03, Laszlo Ersek wrote:
> On 06/13/18 20:20, Laszlo Ersek wrote:
> 
>> * testing on aarch64/KVM:
>>
>> The graphics output looks great as long as I'm in the UEFI shell / the
>> setup TUI / the grub menu. However, once I boot a Fedora 28 Server
>> ISO, and the graphical Anacona Welcome screen appears, I get the exact
>> same display corruption as before, with QemuVideoDxe + the VGA device
>> model. I don't have the slightest idea why that is the case, but it's
>> very visible, if I quickly move the thick blue line cursor around the
>> language and keyboard layout selection lists. It's visible to the
>> naked eye how dirty memory is gradually flushed to the display.

Small (or not so small) technical correction: the problem is that the
guest OS writes directly to DRAM, but QEMU reads from the CPU cache. So
I guess the gradual process that is visible to the naked eye is not
"flushing" but "invalidation"; i.e. as the CPU caches become invalid,
QEMU is gradually forced to reach out to DRAM and finally see what the
guest OS put there. I guess.

More below:

> 
> Wait, I see "efifb" has a parameter called "nowc", and it disables
> write-combining, according to "Documentation/fb/efifb.txt".
> 
> Looking at the source code ("drivers/video/fbdev/efifb.c"), "nowc"
> decides between:
> 
>> 	if (nowc)
>> 		info->screen_base = ioremap(efifb_fix.smem_start, efifb_fix.smem_len);
>> 	else
>> 		info->screen_base = ioremap_wc(efifb_fix.smem_start, efifb_fix.smem_len);
> 
> Am I right to think that *both* of these ioremap() variants map the
> phsyical address range as uncache-able? ("nowc" defaults to "false", and
> I didn't specify "nowc" at all on the kernel command line.)
> 
> Quoting "arch/arm/include/asm/io.h":
> 
>>  * Function             Memory type     Cacheability    Cache hint
>>  * ioremap()            Device          n/a             n/a
>>  * ioremap_nocache()    Device          n/a             n/a
>>  * ioremap_cache()      Normal          Writeback       Read allocate
>>  * ioremap_wc()         Normal          Non-cacheable   n/a
>>  * ioremap_wt()         Normal          Non-cacheable   n/a
> 
> ioremap() implies "device memory" (by definition uncacheable only),
> while ioremap_wc() is normal memory, but UC. Sigh.
> 
> The include file "arch/arm64/include/asm/io.h" doesn't have such helpful
> comments, but it does declare ioremap_cache() at least:
> 
>> extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
> 
> Now, I *guess* if I rebuilt the efifb driver to use ioremap_cache() --
> dependent on a new module parameter or some such --, the Linux guest
> would start working as expected. Unfortunately, the Linux guest is
> already pretty happy with virtio-gpu-pci; the question is how the
> Windows guest would map the EFI framebuffer!
> 
> Unfortunately, I cannot test ARM64 Windows guests ATM.
> 
> So... If the consensus is that the edk2 code simply cannot get better
> than this, and everything else is up to the guest OS(es), then I'm 100%
> willing to push this version (with my minimal updates squashed).

I've just remembered that Drew drew our attention earlier to:

  [PATCH 0/4] KVM/arm64: Cache maintenance relaxations
  http://mid.mail-archive.com/20180517103548.5622-1-marc.zyngier@arm.com

I believe this means that, on an ARMv8.4 host, the ramfb device model
will automatically work, in all guest OSes. If that's the case, I
suggest we merge this series.

Thanks
Laszlo


  reply	other threads:[~2018-06-13 19:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-13  7:29 [PATCH v3 0/4] Add QemuRamfbDxe driver Gerd Hoffmann
2018-06-13  7:29 ` [PATCH v3 1/4] OvmfPkg: add QEMU_RAMFB_GUID Gerd Hoffmann
2018-06-13  7:29 ` [PATCH v3 2/4] OvmfPkg: add QemuRamfbDxe Gerd Hoffmann
2018-06-13 18:20   ` Laszlo Ersek
2018-06-13 19:03     ` Laszlo Ersek
2018-06-13 19:15       ` Laszlo Ersek [this message]
2018-06-13 20:30         ` Ard Biesheuvel
2018-06-13  7:29 ` [PATCH v3 3/4] OvmfPkg: add QemuRamfb to platform console Gerd Hoffmann
2018-06-13  7:29 ` [PATCH v3 4/4] ArmVirtPkg: add QemuRamfbDxe Gerd Hoffmann

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=de71366e-e237-7f31-cc47-2ff705e5bcf7@redhat.com \
    --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