From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4158D211EB809 for ; Wed, 13 Jun 2018 12:03:14 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 92A4940250FF; Wed, 13 Jun 2018 19:03:13 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-122-190.rdu2.redhat.com [10.10.122.190]) by smtp.corp.redhat.com (Postfix) with ESMTP id EBA7C2166BB2; Wed, 13 Jun 2018 19:03:12 +0000 (UTC) From: Laszlo Ersek To: Gerd Hoffmann , Ard Biesheuvel Cc: edk2-devel@lists.01.org References: <20180613072936.12480-1-kraxel@redhat.com> <20180613072936.12480-3-kraxel@redhat.com> <0da06062-431e-385e-0b00-577f1daf3a1e@redhat.com> Message-ID: Date: Wed, 13 Jun 2018 21:03:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <0da06062-431e-385e-0b00-577f1daf3a1e@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 13 Jun 2018 19:03:13 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 13 Jun 2018 19:03:13 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH v3 2/4] OvmfPkg: add QemuRamfbDxe X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 19:03:14 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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. 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). Thanks! Laszlo