From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 F077621E49BB0 for ; Tue, 22 Aug 2017 10:13:38 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id x187so2471076ite.1 for ; Tue, 22 Aug 2017 10:16:11 -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=QastYYMOQZg3EvdhMH6pgT34Bkt0GCabiU5Way7Cpa0=; b=a+Vun8uF09W4NL5/oao9bXt4Ooabl7kzhRebgdUEeqYNnEBC07YD1e6ICJ55/SUkZH aWRYJA6k8V1pt6V1DSpHoU1J02kMeE7reatzIUfcBJuwFqY0w+oz0tgXLDxbbqtKu4e4 MCVk4M7FAAhKP7jxgusgcZOiAdirawQPR5N+M= 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=QastYYMOQZg3EvdhMH6pgT34Bkt0GCabiU5Way7Cpa0=; b=d69DaLuK3nyDAAm5KdUeBEarFbvKPTvHHpeNhtxhVbo7NZfcWwChEOPwyWImNpxYVM nSxZV/s5ncZhG1CwjxexKEdGEFLOjGN8P/EukPA2PZsYwjtnmDKJbrw0vohka4JawmEd poAugT8gdSf8EVNeJTLHIxXSg477+J5T7jwTyHASe83twzC8dRpyKVOQCAQqjSerCFpJ JHmqQvyuQXnWz3KKxLYy1q6aeHYj+5Aa1wzUbp9AorBUDDhRtIz22hsdd7fZPjVVjDgv 8oyPSxp09tN/sVFrnaEqW9X/8vxFX7TDzjFPpxTNJ70Xk82qLTvomwnEKo5Ot59WkJj5 sb4Q== X-Gm-Message-State: AHYfb5gTmMjORVDNdE/r44vXO5Y5hHnrUUz/YIu6vfxTBJZucjDZZglM kRY6/p2iEQd9JXJEYkSefYFIAiIj8Uzv X-Received: by 10.36.93.19 with SMTP id w19mr534290ita.146.1503422171104; Tue, 22 Aug 2017 10:16:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.162.1 with HTTP; Tue, 22 Aug 2017 10:16:10 -0700 (PDT) In-Reply-To: <20170822165729.dj2uha24dtq2oqlf@bivouac.eciton.net> References: <20170822163013.12233-1-ard.biesheuvel@linaro.org> <20170822165729.dj2uha24dtq2oqlf@bivouac.eciton.net> From: Ard Biesheuvel Date: Tue, 22 Aug 2017 18:16:10 +0100 Message-ID: To: Leif Lindholm Cc: "edk2-devel@lists.01.org" , Laszlo Ersek , Jordan Justen 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 17:13:39 -0000 Content-Type: text/plain; charset="UTF-8" On 22 August 2017 at 17: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. GRUB certainly looks like it's > using FrameBufferBase. Maybe that isn't the most important use-case, > but it's certainly not invalid. > This came up at the time, and I /though/ the conclusion was that GRUB hooks into the stack at a higher level. I will give Debian's GRUB a quick spin tomorrow.