Re: [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested

[Doug Anderson]

Will,

On Wed, Sep 10, 2014 at 11:46 AM, Will Deacon <will.deacon@xxxxxxx> wrote:
> On Wed, Sep 10, 2014 at 07:09:59PM +0100, Doug Anderson wrote:
>> On Wed, Sep 10, 2014 at 10:34 AM, Will Deacon <will.deacon@xxxxxxx> wrote:
>> > Setting aside the security model, booting in secure mode can also have a
>> > significant impact on the programming model of system IP, not just the CPU.
>> > For example, the SMMU register file suddenly looks different and the way in
>> > which it is programmed also changes. The GIC (v3+) is similar. Linux doesn't
>> > have drivers that know about this so, whilst not impossible, there's a
>> > non-trivial amount of work (and then maintenance overhead) if you want to
>> > support booting Linux on the secure side.
>>
>> Hrm.  I could have sworn someone told me that exynos5250-snow is
>> booted in Secure SVC mode and has been that way forever.  I could
>> certainly be wrong.  Stupid question, but should any of your
>> statements apply to an A15 or an A12?  Maybe things change with newer
>> CPUs?
>
> Snow does boot secure, which is why you don't get KVM without hacking the
> bootloader. However, snow also doesn't use:

Well, you could get KVM if the kernel knew to switch from "secure SVC"
to "nonsecure HYP", right?  ...so one bonus of implementing this (for
32-bit ARM only, of course) is that legacy systems (like snow) would
magically get KVM without replacing the bootloader...


> Again, this isn't the kind of platform I was referring to. Until recently,
> (32-bit) Linux has booted in secure svc just fine and there's no reason to
> break platforms relying on that.

Yup, exactly.  I'm definitely not on the cutting edge here.  Just
working on plain old boring 32-bit systems.  ;)  I have even less
knowledge about 64-bit systems than 32 bit if that can be believed.
;)


> Just to reiterate, you're talking ARMv7 and I'm talking ARMv8. For ARMv7,
> there is a separate argument about whether we should make bootloaders
> simple and the OS more complex, which has been had on the mailing list
> before (I don't think there was a good conclusion though -- Nico and Catalin
> were discussing about MCPM and PSCI, which is very much related to this
> topic).

Yup.  I'm super happy that folks are figuring this out. :)  I think my
viewpoint / position is adequately clear at this point, so I'll step
back and let the experts work something out and focus my attention on
kitchens that have fewer chefs.  If things need to be different on
ARMv8 then the folks working on those system will need to solve these
problems.  ...but it would be nice if we weren't forced to solve them
on 32-bit.



>> > The secure world may be more permissive in some regards, but it's actually
>> > a burden in others. It's not a simple superset of non-secure, and this is
>> > more evident than ever in ARMv8.
>> >
>> > As I understand it, this conversation started because we're booting at
>> > non-secure EL1 with a badly configured EL2. That sounds like something
>> > we may have to fix/work around in Linux (Olof points out that it used to
>> > work), but we shouldn't conflate that with booting on the secure side to
>> > get away from broken firmware.
>>
>> See above and also my summary to Mark Rutland.  I don't think your
>> statement above is quite where we're at, but hopefully we're on the
>> same page now.  :)
>
> If `where we're at' is trying to boot an ARMv7 product, then you can boot in
> secure svc and lose virtualisation support. Looking forward to ARMv8, this
> isn't going to work, so I'd encourage you to start thinking about getting
> a working bootloader as a requirement.

Yup, definitely on the same page now.  With everyone working on this
I'd imagine that there will be some nice standards worked out by the
time real ARMv8 is ready to ship?

...so would you say that you're in support of landing the patch to
allow physical counters?  I know Olof has Acked the patch above, but
it's nice if there's general agreement that it's OK.


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/