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 5E2D821297051 for ; Wed, 13 Jun 2018 12:15:09 -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 7DF6C401EF30; Wed, 13 Jun 2018 19:15:08 +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 48FB32166BB2; Wed, 13 Jun 2018 19:15:07 +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:15:06 +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: 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.5]); Wed, 13 Jun 2018 19:15:08 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 13 Jun 2018 19:15:08 +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:15:09 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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