Re: [PATCH] ArmVirtPkg: remove QemuVideoDxe from ArmVirtQemu and ArmVirtQemuKernel

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 22 August 2017 at 20:05, Leif Lindholm <leif.lindholm@linaro.org> 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:
>> <http://mid.mail-archive.com/1485987247-16230-1-git-send-email-agraf@suse.de>.
>>
>> (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.