On 06/13/18 22:30, Ard Biesheuvel wrote: > On 13 June 2018 at 21:15, Laszlo Ersek <ler...@redhat.com> wrote: >> 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. >> > > I am not sure how I managed to confuse myself into thinking that ramfb > would solve the coherency issue on ARM, but unfortunately, the > observed behavior is exactly as expected. The framebuffer is still > located in RAM that is mapped cacheable by the host and non-cacheable > by the guest. > > There is a notable difference though: this time, the efifb framebuffer > is identifiable as ordinary [although reserved] memory by the guest, > and so I think it is reasonable for the efifb driver to check whether > the memory is covered by a region in the UEFI memory map that has the > EFI_MEMORY_WB attribute, in which case it is permitted to use a > cacheable mapping. >
OK. Thank you for pointing this out! So, with the testing and related discussion up-thread, for the series: Tested-by: Laszlo Ersek <ler...@redhat.com> Pushed as commit range e03a460f061a..c64688f36a8b. In addition, I've now closed <https://bugzilla.tianocore.org/show_bug.cgi?id=785>. Thank you very much Gerd for this work! Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel