| Message ID | cover.d9b2d7d69cc351a30963d653b1d459c878356e4e.1571888583.git-series.marmarek@invisiblethingslab.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Optionally call EFI SetVirtualAddressMap() | expand |
On 24.10.19 05:45, Marek Marczykowski-Górecki wrote: > Workaround buggy UEFI accessing boot services memory after ExitBootServices(). > Patches discussed here: > https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00701.html > > In addition to the tests below, I've tested kexec on xen.efi with this option > enabled and it (still) works. > > Test results on few laptops: > > Thinkpad x230, firmware version 2.77: > - without the patch: crashes on RS call (mapbs helps) > - with patch: works > - same with xen.efi and MB2 > > Librem 14 v1, firmware version (AMI) ARUD026 (06/18/2015): > - without the patch: works > - with the patch: works > - same with xen.efi and MB2 > > Dell Latitude E6420, firmware version A21: > this machine requires efi=attr=uc workaround > - without the patch: dom0 hangs before sending any message to the console (even with earlyprintk=xen etc) > - with the patch: crashes before dom0 prints anything: mm.c:896:d0v0 non-privileged attempt to map MMIO space 2c2c2c2c2c > - same with xen.efi and MB2 > > Thinkpad W540: > - without the patch: crashes on RS call (only efi=no-rs helps) > - with patch: works > - tested only with MB2 > > Thinkpad X1 Carbon gen5, firmware version 1.22 (2017-07-04): > - without the patch: works > - with patch: works > - tested only xen.efi > > Thinkpad P52, firmware version 1.25 (2018-04-15): > - without the patch (MB2): hangs on RS call (mapbs helps) > - without the patch (xen.efi): works(?!) > - with the patch: works > - tested with xen.efi and MB2 > > Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> > > Dell Latitude 5580, firmware 1.16.0 > - without the patch: works > - with patch: works > - tested only xen.efi > > Tested-by: Jason Andryuk <jandryuk@gmail.com> > > Changes in v2: > - fix boot with xen.efi (efi_memmap at this point still needs to be accessed > via physical address). TBH, I don't understand why previous version worked > with MB2 - is directmap mapped at this point? > Changes in v4: > - reword commit messages, drop mentions of kexec > - new patch (3) > > Cc: Juergen Gross <jgross@suse.com> > Cc: Andrew Cooper <andrew.cooper3@citrix.com> > Cc: George Dunlap <George.Dunlap@eu.citrix.com> > Cc: Ian Jackson <ian.jackson@eu.citrix.com> > Cc: Jan Beulich <jbeulich@suse.com> > Cc: Julien Grall <julien.grall@arm.com> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Cc: Stefano Stabellini <sstabellini@kernel.org> > Cc: Tim Deegan <tim@xen.org> > Cc: Wei Liu <wl@xen.org> > Cc: Jason Andryuk <jandryuk@gmail.com> > > Marek Marczykowski-Górecki (3): > efi: remove old SetVirtualAddressMap() arrangement > xen/efi: optionally call SetVirtualAddressMap() > xen/efi: use directmap to access runtime services table > > xen/common/Kconfig | 10 ++++++++- > xen/common/efi/boot.c | 52 +++++++++++++++++++++++------------------ > xen/common/efi/runtime.c | 19 +++------------ > 3 files changed, 44 insertions(+), 37 deletions(-) > > base-commit: 7a4e6711114905b3cbbe48e81c3222361a7f3579 > For the series: Release-acked-by: Juergen Gross <jgross@suse.com> Juergen