From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 CD8CD21E49BD1 for ; Tue, 22 Aug 2017 12:03:17 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id b189so419684wmd.0 for ; Tue, 22 Aug 2017 12:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=rJapEnVfkgHw4Bn740nZkmm5BASqvU97prgUMoPp7RY=; b=G9wvkVaP83iAL95S4WC7zoUMRweUS/P69B6eXsnSppW7EeMiVffIF7oQ2fN4mg8F7j jBSleVC/v73PR2mflzIBWiua3U4jffDSk7i3t6mJBLiMR0FOgyGk4KReNoemddJzy8uz Z4+QEPPua3ya9gm74eaNVKy6PEPv9AMRpqkcM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=rJapEnVfkgHw4Bn740nZkmm5BASqvU97prgUMoPp7RY=; b=OKQY5OnC4RzR3bm2cu0hnXleRb/Y6f+bee7VWhbmZIq+OFHpuWE/I1WjXJAJxxHwqx p/GSZhwHNlZM7r+x7DToCCULAUYXn66wgVObPSnZIlpsLxZ8KbfmDaa5Pol7R+hn3ojK sJKOHVzIo313Q6uRfJlZY95B0W8CG/kPJVdGIqgHMomrCKem3Wb4UQMoRvOV+rqXt1J3 2/YrmaG5ppOx0UYP23CvQXcSyhLkYIUiEFRvuKKB4slJGZwOUhlO2hrAXmZXNdgqHofH StSSAWvIBRwie4sK6oqaKm9Ra6uY2BtfkaUnl0sunJH/4vzhg+yUt69BpyL6H+IcOcNW v9NQ== X-Gm-Message-State: AHYfb5g5EiS5KBrWqAUjsVOnioAuNrAitH/ewXoTBUYD06DBJmXuDivp HpLTuoAHwEjjblML X-Received: by 10.28.145.2 with SMTP id t2mr303176wmd.179.1503428749112; Tue, 22 Aug 2017 12:05:49 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id o24sm49863wmi.8.2017.08.22.12.05.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 22 Aug 2017 12:05:48 -0700 (PDT) Date: Tue, 22 Aug 2017 20:05:45 +0100 From: Leif Lindholm To: Laszlo Ersek Cc: Ard Biesheuvel , edk2-devel@lists.01.org, jordan.l.justen@intel.com, Alexander Graf Message-ID: <20170822190545.actuljiqfzq4fdkx@bivouac.eciton.net> References: <20170822163013.12233-1-ard.biesheuvel@linaro.org> <20170822165729.dj2uha24dtq2oqlf@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [PATCH] ArmVirtPkg: remove QemuVideoDxe from ArmVirtQemu and ArmVirtQemuKernel X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 19:03:18 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Aug 22, 2017 at 07:38:03PM +0200, Laszlo Ersek wrote: > On 08/22/17 18:57, Leif Lindholm wrote: > > On Tue, Aug 22, 2017 at 05:30:13PM +0100, Ard Biesheuvel wrote: > >> One of the reasons for introducing virtio-gpu support to OvmfPkg and > >> ArmVirtpkg was the fact that under KVM virtualization on ARM, the > >> legacy VGA cannot be used reliably. This is due to an implementation > >> detail of QEMU+KVM, which remaps cached host memory into the guest > >> address space as a framebuffer behind a PCI BAR. Given that the purpose > >> of a memory mapped framebuffer is its side effects, such BARs should > >> never be mapped cacheable in the guest, and the mismatched attributes > >> between host and guest result in a loss of coherency, visible as > >> corruption in the framebuffer image. > >> > >> This issue does not occur under TCG emulation, nor did we expect it to > >> actually bring down the guest under KVM, and so it was deemed harmless > >> to keep support for the VGA device as well. However, as it turns out, > >> the fact that the framebuffer BAR is mapped using device semantics by > >> default may result in unalignment faults when we use the ordinary string > >> copy routines on the contents. In theory, we could work around this by > >> remapping the BAR as write combining, but it appears the generic PCI > >> bus driver does not actually implement this. > >> > >> So let's remove the QemuVideoDxe driver altogether. This may result > >> in loss of functionality for use cases that rely on the framebuffer > >> to be directly addressable (such as EFIFB), but given that this never > >> worked reliably under KVM in the first place, let's not let that stop > >> us from dropping support for it. > > > > For the record, this would most likely mean we would not be able to > > test graphical installers on QEMU. > > Hmmm, RHEL-7.3+ (and Fedora 2x+, for some "x" I don't recall), for > Aarch64, definitely install in GUI mode, on virtio-gpu-pci, *including* > a perfectly working grub2. I'd been obsessed with this (i.e., a fully > graphical installation in aarch64/KVM guests). OK, good, then our goals are aligned. > I also have GUI-enabled openSUSE Tumbleweed and Ubuntu guests on my > Mustang. I've booted them just now, and their grub2's work flawlessly. > These guests are not new, the installer ISO names are: > > - openSUSE-Tumbleweed-DVD-aarch64-Snapshot20161031-Media.iso > - ubuntu-16.04.2-server-arm64.iso > > I remember that for the Ubuntu installation, I had to pick the "HWE > kernel" from the grub menu. > > I've uploaded a few screenshots here: > > https://people.redhat.com/lersek/aarch64-vgpu-screenshots-7c6bb412-923d-468b-8cfa-5894abd90b40/ > > > GRUB certainly looks like it's > > using FrameBufferBase. > > Please see this (quite small) grub2 patch: > . > > (See also the responses from phcoder.) > > > Maybe that isn't the most important use-case, > > but it's certainly not invalid. > > To me personally, the use case you describe is extremely important (see > above). My impression has been that this has been sorted out for ages. > At least Alex Graf posted the grub2 patch in Feb 2017 (CC'ing him now). Yes, grub work pretty much seized for anything other than preparing the release until that happened, and then stalled for a while (presumably down to recovery). > ... FWIW, as far as I can see, Fedora and RHEL do *not* carry Alex's > grub2 patch. Yet grub2 works just fine with virtio-gpu-pci (BLT only). "works just fine" is not the same as "are unaffected by the lack of direct framebuffer access". I will have a skim through the code and see what (if any) situations could cause direct accesses to the framebuffer. > Not sure about the grub2 details, but I consider this problem (graphical > GNU/Linux installers in aarch64 guests, using virtio-gpu-pci) solved; > cross-distro. If we have a way to resolve this situation, I do not religiously oppose a temporary breakage. However, if we (for example) end up with "upstream GRUB won't be able to test the graphic installer of Debian Stable for the next two years", that will be inconvenient. Best Regards, Leif > Thanks, > Laszlo > > >> Contributed-under: TianoCore Contribution Agreement 1.1 > >> Signed-off-by: Ard Biesheuvel > >> --- > >> ArmVirtPkg/ArmVirtQemu.dsc | 2 -- > >> ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 - > >> ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 -- > >> 3 files changed, 5 deletions(-) > >> > >> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc > >> index e23a6d17bc44..2e6e76224987 100644 > >> --- a/ArmVirtPkg/ArmVirtQemu.dsc > >> +++ b/ArmVirtPkg/ArmVirtQemu.dsc > >> @@ -57,7 +57,6 @@ > >> BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf > >> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf > >> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf > >> - FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf > >> QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf > >> FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf > >> PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf > >> @@ -357,7 +356,6 @@ > >> # > >> # Video support > >> # > >> - OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf > >> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf > >> OvmfPkg/PlatformDxe/Platform.inf > >> > >> diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc > >> index 237b2d03a714..3194aa3edc8e 100644 > >> --- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc > >> +++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc > >> @@ -167,7 +167,6 @@ READ_LOCK_STATUS = TRUE > >> # > >> # Video support > >> # > >> - INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf > >> INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf > >> INF OvmfPkg/PlatformDxe/Platform.inf > >> > >> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc > >> index aa01debfda69..69de887277cb 100644 > >> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc > >> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc > >> @@ -57,7 +57,6 @@ > >> BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf > >> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf > >> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf > >> - FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf > >> QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf > >> FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf > >> PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf > >> @@ -348,7 +347,6 @@ > >> # > >> # Video support > >> # > >> - OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf > >> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf > >> OvmfPkg/PlatformDxe/Platform.inf > >> > >> -- > >> 2.11.0 > >> >