From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::241; helo=mail-it0-x241.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8D09B21155D3B for ; Wed, 13 Jun 2018 13:30:13 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id l6-v6so5729082iti.2 for ; Wed, 13 Jun 2018 13:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9w9mDmdk0GSBDaxmx8bi5pbSy6c+kDxnliH0mFtkhH0=; b=jntQCR7JRgoeEwpWg93x+FDyyT6u+NAVK/ScyyrHa+N+bulgworwR23HIOgpg8KWm9 K71GyzMhSHENsE7Jtoyhm+pgn+BVNj+RJu+kMkKd1JnoiyUBQbCheCQ1msgrxjQ6MGz6 KseMy85YfbwBra7uaS1DpAoxB2VjYA4yvzXrk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9w9mDmdk0GSBDaxmx8bi5pbSy6c+kDxnliH0mFtkhH0=; b=a/C1YDlAAHay2Tg0Y2CcYBikUULiNWeqmKve2bceQY+egkgmDrqAzBYw1a5lX0mI8g TWPttRQh8qlVApbXoVdL0bV1cY7wZ+MJkv93GZt1fTsDY2svO7pTRn9OinwJE/IngYGe /9O/ahoITJ10dUnKZU6e1YFt8n9X0sIHxCSQQ6LOc9s7g2/zAG0CBsbSCkGoHgbR9Uhv v9d2Rd4eMpdwuGgruOFASXJULdbz1uYbhr76XqvlUBIscy4RAcl4ilQAnur1l0sZuW3i W8mxkyKrsQCTrIWb41AqcKv1akZUKJnYUBVZun6JoKHwRyjRLW+XjjVOgID3U6I/j/+M qYBA== X-Gm-Message-State: APt69E0f2CmKalbbyFidwG885YuSsczJUveBOEyCxVI+GQTkcVkS6pyu SgCRnBOhObkvVxYBWESmQyAaVS3w11s0QIPVu1r0BQ== X-Google-Smtp-Source: ADUXVKJDSIgczvDJ+NtW1cleXudgF3etcTbdKSceqEw5741xK+Q1eZmePDbkAY49isGXXz1IoT1Xrrz82NT8e3/zYlE= X-Received: by 2002:a02:6001:: with SMTP id i1-v6mr1043648jac.5.1528921812501; Wed, 13 Jun 2018 13:30:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bbc7:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 13:30:11 -0700 (PDT) In-Reply-To: References: <20180613072936.12480-1-kraxel@redhat.com> <20180613072936.12480-3-kraxel@redhat.com> <0da06062-431e-385e-0b00-577f1daf3a1e@redhat.com> From: Ard Biesheuvel Date: Wed, 13 Jun 2018 22:30:11 +0200 Message-ID: To: Laszlo Ersek Cc: Gerd Hoffmann , "edk2-devel@lists.01.org" 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 20:30:13 -0000 Content-Type: text/plain; charset="UTF-8" On 13 June 2018 at 21:15, Laszlo Ersek 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.