On 8 December 2015 at 14:05, Cohen, Eugene <eug...@hp.com> 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?
>
I fully agree, and this is exactly why I asked Michael to share the
contents of his ID_MMFR0 system register. Could you do the same,
please, for this particular platform?
The idea is that we could use the information that is exposes
regarding how shareability is implemented to decide whether to use the
shareable attribute or not (i.e., use the same behavior the PCD gives
you in that case)
--
Ard.
>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>> Of Michael Zimmermann
>> Sent: Monday, November 16, 2015 8:04 AM
>> To: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Heyi Guo
>> <heyi....@linaro.org>; Leif Lindholm <leif.lindh...@linaro.org>
>> 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
>> <ard.biesheu...@linaro.org>
>> wrote:
>>
>> >
>> >
>> > On 16 nov. 2015, at 15:44, Michael Zimmermann
>> <sigmaepsilo...@gmail.com>
>> > 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
>> <ard.biesheu...@linaro.org
>> > > wrote:
>> >
>> >> On 14 November 2015 at 14:39, Michael Zimmermann
>> >> <sigmaepsilo...@gmail.com> 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
>> <mark.rutl...@arm.com>
>> >> 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
>> >> >> edk2-devel@lists.01.org
>> >> >> https://lists.01.org/mailman/listinfo/edk2-devel
>> >> >
>> >> >
>> >>
>> >
>> >
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
