On 22 August 2017 at 20:05, Leif Lindholm <[email protected]> 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/[email protected]>. >> >> (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. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
