| Message ID | 20180615104818.23013-1-ard.biesheuvel@linaro.org |
|---|---|
| Headers | show |
| Series | efi: add support for cacheable efifb mappings | expand |
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. What command line did you use? From my earlier testing (which obviously couldn't include your present patches): http://mid.mail-archive.com/0da06062-431e-385e-0b00-577f1daf3a1e@redhat.com the important options are "-nodefaults" plus "-device ramfb". This makes sure that no hardware appears in the VM that the Linux guest could consider "video hardware" in its own right. So the only console possibility will be efifb, and no other (more specific / higher prio) fb driver will be able to eject it. I'll try to come back with test results too. Thanks Laszlo > > 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(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 15 June 2018 at 14:37, Laszlo Ersek <lersek@redhat.com> 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. > > What command line did you use? From my earlier testing (which obviously > couldn't include your present patches): > > http://mid.mail-archive.com/0da06062-431e-385e-0b00-577f1daf3a1e@redhat.com > > the important options are "-nodefaults" plus "-device ramfb". This makes > sure that no hardware appears in the VM that the Linux guest could > consider "video hardware" in its own right. So the only console > possibility will be efifb, and no other (more specific / higher prio) fb > driver will be able to eject it. > OK, so I was using the wrong -device, using just 'ramfb' works fine. > I'll try to come back with test results too. > Thanks! >> >> 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(-) >> > -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@redhat.com> Thanks! Laszlo -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 15 June 2018 at 18:38, Laszlo Ersek <lersek@redhat.com> 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@redhat.com> > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 15 June 2018 at 18:39, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 15 June 2018 at 18:38, Laszlo Ersek <lersek@redhat.com> 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@redhat.com> >> > > Thanks! Very happy to hear that ... Peter, any objections? If not, I will resend them with Laszlo's T-b and cc the fbdev list and maintainer to get this into v4.19 Thanks, Ard. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html