On 07/29/2015 09:32 PM, Lee, Chun-Yi wrote: > When testing hibernate, I found the EFI runtime services was broken > on some old EFI machines on my hand, Intel DQ57TM development board > and Acer Gateway Z5WT2 notebook. > > After printing the EFI memmap and virtual address mapping on -4G area, > found those issue machines keep the physical address of Runtime > Data/Code regions unchanged but not Boot Data/Code. The logs were > attached on openSUSE bug: > https://bugzilla.suse.com/show_bug.cgi?id=939979 > > Due to Boot Data/Code can be used by OS as available memory regions, > so those old EFI BIOS do not keep the physical address of Boot regions > unchanged. But, address of Runtime regions are the same. > > On Intel DQ57TM, sometimes the order of EFI Boot regions changed. On > Acer Gateway Z5WT2, the amount of EFI Boot regions changed. > > The above changing of EFI Boot regions causes the EFI Runtime Data/Code > may not mapping to constant virtual address, that's because the EFI Boot > and Runtime regions are interleaved and EFI va mapping applied PMD > 2M-aligned logic. > > A workaround of this situation is mapping Boot and Runtime regions to > different starting virtual address. Then the changing of Boot Data/Code > regions will not affect to the virtual address mapping to Runtime > Data/Code. > > This patch adds codes for mapping Boot Data/Code regions start from > 0xffff_ffff_0000_0000, has 1G space. And mapping Runtime Data/Code > regions start from 0xffff_fffe_c000_0000 that has 63G space. > This changelog is at least partially incomprehensive. It also seems more than a bit aggressive to expect that 1 GB will be sufficient forever. -hpa -- 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