From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 0F84021D2E628 for ; Tue, 22 Aug 2017 12:12:13 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id x187so374922ite.1 for ; Tue, 22 Aug 2017 12:14:46 -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=xz1d5xhZJxHuDZHXXGP8EERO1q8Z1tkALz31/E+qhEk=; b=QwElpVVUIeJXVStJuDJpKn+qSeKee5E9RYHEs07PwyrKY/3xdCj9UtlnGzzabTGzZI ASuZruiBvwIOQU2LrI8usL+IfghQ/nDt9lDSglTFHOx+ytKBAMtrMvqXSHRBKboZZ2R/ zli3OPMkA0wWorRiR0guzAzUF+WRT4VLOp2PI= 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=xz1d5xhZJxHuDZHXXGP8EERO1q8Z1tkALz31/E+qhEk=; b=ELbXrE/aX6ETBEk7fhahqmNi7qUwMtK7VoYZcI6F9xjRd7vZxy5IPSon4NK3Ndma7y bZbZfF/6zGKReXUVJ4+IhovB6jYqRdc3bzi3KqnOMvcXiMKaiUo0oOLSdoYGyeZYoVj6 PKUUYJq0X6Q7ieFpR9bswHgrzXAfrLXHMwoxmIcAIW6jmd9rvNtgrrehWj6IbIUu9SNp 6S9txzCYFGcwjrsMTDpw7ltuvQRyO8inFw/yqIZQ4MPU3vGTLR5lyExi0uXYZ463rGVF W8ktvE9ZIbvpTZNaR6t9VmK8r9W9uctLS4WXA5/GKxTt67K8oug8IbF7ypb3NsBkmUit LgBQ== X-Gm-Message-State: AHYfb5jIgE0fbbDlO4ldK3Y7PvbcigBbS+gy6AFlOutMeZkx7wmjJeDB l8rsd9HMKUmiURgckIj76NGFach3rO9n X-Received: by 10.36.93.19 with SMTP id w19mr813295ita.146.1503429285283; Tue, 22 Aug 2017 12:14:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.162.1 with HTTP; Tue, 22 Aug 2017 12:14:44 -0700 (PDT) In-Reply-To: <20170822190545.actuljiqfzq4fdkx@bivouac.eciton.net> References: <20170822163013.12233-1-ard.biesheuvel@linaro.org> <20170822165729.dj2uha24dtq2oqlf@bivouac.eciton.net> <20170822190545.actuljiqfzq4fdkx@bivouac.eciton.net> From: Ard Biesheuvel Date: Tue, 22 Aug 2017 20:14:44 +0100 Message-ID: To: Leif Lindholm Cc: Laszlo Ersek , "edk2-devel@lists.01.org" , Jordan Justen , Alexander Graf 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:12:13 -0000 Content-Type: text/plain; charset="UTF-8" On 22 August 2017 at 20:05, Leif Lindholm wrote: > 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. > I *think* there is no disagreement here, only Laszlo and I were under the impression that this was a solved issue. Interestingly, some GRUB versions without the patch also work, including Ubuntu's, so I wonder what the deal is here. I'll dig into this tomorrow.