On 8 December 2015 at 14:05, Cohen, Eugene <[email protected]> wrote:
> I'd like to dig up this thread because I suspect there's something that is
> fundamentally misunderstood.
>
> On at least one older non-MP processor (Cortex-A8) this change just forces
> all accesses to be uncached - this is true for L1 I+D and L2. There's
> nothing strange about the L2 subsystem or bus in this case, this is just
> vanilla Cortex-A8. So why should we have to set an obscure PCD override
> (PcdNormalMemoryNonshareableOverride added later) just to make the darn
> thing work?
>
> So the original rationale ("shareable is best") does not align with the
> hardware produced by ARM which, for at least one mainstream processor, means
> "shareable is uncached".
>
> Can we reconsider the logic being used so that everyone with a uniprocessor
> or Cortex A8 (or whatever the real exposure is) doesn't have to independently
> debug why caching has broken as of this revision? I'm thinking the logic
> could be refined to something like "If the processor is MP capable then set
> shareable, otherwise clear it". Could we do something like that?
>
> Thanks,
>
> Eugene
>
>> -----Original Message-----
>> From: edk2-devel [mailto:[email protected]] On Behalf
>> Of Michael Zimmermann
>> Sent: Monday, November 16, 2015 8:04 AM
>> To: Ard Biesheuvel <[email protected]>
>> Cc: [email protected] <[email protected]>; Heyi Guo
>> <[email protected]>; Leif Lindholm <[email protected]>
>> Subject: Re: [edk2] [PATCH] ArmPkg/ArmLib: mark all cached mappings
>> as (inner) shareable
>>
>> Unfortunately I can't tell you much about how the L2 works or if it's
>> configurable because it's a proprietary hw(I'm a opensource dev
>> working
>> with Qualcomm Android devices).
>>
>> Also, I'm using ARM PrePi so EDK2 doesn't configure any architectural
>> hw
>> besides exceptions and MMU.
>>
>> maybe this kernel driver can be useful:
>> https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm
>> /mach-msm/msm-krait-l2-accessors.c?h=LA.AF.2.1_rb1.2
>>
>> On Mon, Nov 16, 2015 at 3:52 PM, Ard Biesheuvel
>> <[email protected]>
>> wrote:
>>
>> >
>> >
>> > On 16 nov. 2015, at 15:44, Michael Zimmermann
>> <[email protected]>
>> > wrote:
>> >
>> > What's the 2nd commit? The one I'm talking about 'ArmPkg/ArmLib:
>> mark all
>> > cached mappings as (inner) shareable':
>> >
>> >
>> https://github.com/tianocore/edk2/commit/0c9a522f28772049ae37c8
>> 5b8ae589a98d2d3b81
>> >
>> >
>> > OK. Thanks for clearing that up.
>> >
>> > Are you using an external L2 (e.g., a PL220), and if so, can you
>> configure
>> > it to ignore the S bit?
>> >
>> > On Mon, Nov 16, 2015 at 1:11 PM, Ard Biesheuvel
>> <[email protected]
>> > > wrote:
>> >
>> >> On 14 November 2015 at 14:39, Michael Zimmermann
>> >> <[email protected]> wrote:
>> >> > I have an issue with this commit too on my ARMv7 device.
>> >> > It causes the whole system to get extremely slow.
>> >> >
>> >>
>> >> Since you are top posting a reply into a thread that references two
>> >> separate changes (the one that started the thread and the one
>> >> mentioned in the message you are replying to), could you please
>> >> indicate which exact commit is causing your performance
>> problems?
>> >>
>> >> Thanks,
>> >> Ard.
>> >>
>> >>
>> >> > 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
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
