I have an issue with this commit too on my ARMv7 device. It causes the whole system to get extremely slow.
This is my memmap in case it matters: Type Start End # Pages Attributes Available 0000000080200000-0000000088DFFFFF 0000000000008C00 000000000000000F Available 0000000089000000-00000000890FFFFF 0000000000000100 000000000000000F BS_Data 0000000089100000-00000000898FFFFF 0000000000000800 000000000000000F Available 0000000089900000-0000000089FFFFFF 0000000000000700 000000000000000F BS_Data 000000008A000000-000000008A3FFFFF 0000000000000400 000000000000000F Available 000000008A400000-000000008ABFFFFF 0000000000000800 000000000000000F Available 000000008AE00000-000000008B3EFFFF 00000000000005F0 000000000000000F BS_Data 000000008B3F0000-000000008BBFFFFF 0000000000000810 000000000000000F Available 000000008BC00000-000000008D9FFFFF 0000000000001E00 000000000000000F Available 000000008EC00000-000000008EFFFFFF 0000000000000400 000000000000000F Available 000000008F700000-000000008FDFFFFF 0000000000000700 000000000000000F Available 000000008FF00000-00000000BACF2FFF 000000000002ADF3 000000000000000F LoaderCode 00000000BACF3000-00000000BADAFFFF 00000000000000BD 000000000000000F LoaderData 00000000BADB0000-00000000BADB5FFF 0000000000000006 000000000000000F LoaderCode 00000000BADB6000-00000000BAEEBFFF 0000000000000136 000000000000000F BS_Code 00000000BAEEC000-00000000BAFA8FFF 00000000000000BD 000000000000000F RT_Data 00000000BAFA9000-00000000BAFAEFFF 0000000000000006 800000000000400F RT_Code 00000000BAFAF000-00000000BAFB1FFF 0000000000000003 800000000002000F RT_Data 00000000BAFB2000-00000000BAFC2FFF 0000000000000011 800000000000400F RT_Data 00000000BAFC3000-00000000BAFC3FFF 0000000000000001 800000000000400F RT_Code 00000000BAFC4000-00000000BAFCDFFF 000000000000000A 800000000002000F RT_Data 00000000BAFCE000-00000000BAFEFFFF 0000000000000022 800000000000400F RT_Data 00000000BAFF0000-00000000BAFF0FFF 0000000000000001 800000000000400F RT_Code 00000000BAFF1000-00000000BAFF2FFF 0000000000000002 800000000002000F RT_Data 00000000BAFF3000-00000000BAFF4FFF 0000000000000002 800000000000400F Available 00000000BAFF5000-00000000BE483FFF 000000000000348F 000000000000000F BS_Data 00000000BE484000-00000000BE51AFFF 0000000000000097 000000000000000F Available 00000000BE51B000-00000000BE53FFFF 0000000000000025 000000000000000F BS_Data 00000000BE540000-00000000BFE28FFF 00000000000018E9 000000000000000F Available 00000000BFE29000-00000000BFEBAFFF 0000000000000092 000000000000000F BS_Code 00000000BFEBB000-00000000BFFB8FFF 00000000000000FE 000000000000000F RT_Data 00000000BFFB9000-00000000BFFB9FFF 0000000000000001 800000000000400F RT_Code 00000000BFFBA000-00000000BFFBCFFF 0000000000000003 800000000002000F RT_Data 00000000BFFBD000-00000000BFFBFFFF 0000000000000003 800000000000400F RT_Code 00000000BFFC0000-00000000BFFC1FFF 0000000000000002 800000000002000F RT_Data 00000000BFFC2000-00000000BFFC4FFF 0000000000000003 800000000000400F RT_Code 00000000BFFC5000-00000000BFFC5FFF 0000000000000001 800000000002000F RT_Data 00000000BFFC6000-00000000BFFC8FFF 0000000000000003 800000000000400F RT_Code 00000000BFFC9000-00000000BFFCAFFF 0000000000000002 800000000002000F RT_Data 00000000BFFCB000-00000000BFFFEFFF 0000000000000034 800000000000400F BS_Data 00000000BFFFF000-00000000BFFFFFFF 0000000000000001 000000000000000F Available 00000000C0000000-00000000FFFFFFFF 0000000000040000 000000000000000F On Thu, Nov 12, 2015 at 3:03 PM, Mark Rutland <[email protected]> wrote: > On Thu, Nov 12, 2015 at 11:35:28AM +0000, Leif Lindholm wrote: > > Hi Ard, > > > > On Mon, Nov 09, 2015 at 02:18:58PM +0100, Ard Biesheuvel wrote: > > > Mark all cached memory mappings as shareable (or inner shareable on > > > AArch64) so that our view of memory is kept coherent by the hardware. > > > > > > This is primarily relevant under virtualization (where a guest may > migrate > > > to another core) but in general, since UEFI on ARM is mostly used in a > > > context where the secure firmware and possibly a secure OS are already > up > > > and running, it is best to refrain from using any non-shareable > mappings. > > > > Thanks, this is both an important correctness fix and nice code > > cleanup. > > > > I ran into an issue while testing this, which is why I haven't > > responded to this, but I've bisected it down to r18503/3a05b13, and am > > looking into what causes an issue with Linux booting. > > FWIW, I had issues with that which Ard worked around for virtual > machines in r18533/2f71ad11d6eaa2af ("ArmVirtPkg: reduce preallocation > of boot services data pages"). > > You may be suffering a similar issue. > > Thanks, > Mark. > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
