On 15 June 2018 at 18:38, Laszlo Ersek <lersek@xxxxxxxxxx> wrote: > On 06/15/18 12:48, Ard Biesheuvel wrote: >> KVM guests on ARM have special requirements when it comes to mapping >> framebuffers: given that the host [emulating the framebuffer] uses >> cacheable accesses to read from the framebuffer region, the guest >> should uses cacheable accesses as well, or coherency is lost, i.e., >> the host does not see what the guest writes. >> >> Modifying PCI drivers to take this into account just for KVM on ARM is >> unreasonable, given that mapping BARs cacheable and still expecting >> side effects does not make any sense. However, doing the same for >> regions of system memory does make sense, since a framebuffer in DRAM >> could be accessed via DMA by a coherent master, and so it makes sense >> to take the memory attributes described by the UEFI memory map into >> account if it covers the efifb region. >> >> Patch #2 implements this. Patch #1 is a preparatory patch that makes >> efi_mem_desc_lookup() usable for us in #2. >> >> Question is how to best test this. I tried Gerd's ramfb patches against >> QEMU with a recent ArmVirtQemu build but I am having trouble getting my >> console to use the EFI framebuffer. >> >> Ard Biesheuvel (2): >> efi: drop type and attribute checks in efi_mem_desc_lookup() >> fbdev/efifb: honour UEFI memory map attributes when mapping the fb >> >> arch/x86/platform/efi/quirks.c | 3 +- >> drivers/firmware/efi/efi.c | 8 +-- >> drivers/firmware/efi/esrt.c | 5 +- >> drivers/video/fbdev/efifb.c | 52 ++++++++++++++++---- >> 4 files changed, 49 insertions(+), 19 deletions(-) >> > > I reproduced the issue using the latest stock F28 kernel in the KVM > guest, on my Mustang A3 host. Then I built this set on top of > v4.17-12074-g4c5e8fc62d6a, using the F28 kernel config. I didn't pass > any parameters to efifb. The series works perfectly for me. > > Tested-by: Laszlo Ersek <lersek@xxxxxxxxxx> > Thanks! Very happy to hear that ... -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
