Hi Marc, David,
On 2018/11/23 19:09, Marc Zyngier wrote:
> Hi Hanjun,
>
> On 23/11/2018 09:40, Hanjun Guo wrote:
>> Hi Marc,
>>
>> On 2018/11/23 17:10, Marc Zyngier wrote:
>>> On 23/11/2018 01:25, Hanjun Guo wrote:
>>>> On 2018/10/31 22:04, David Long wrote:
>>>>> From: "David A. Long" <dave.long@xxxxxxxxxx>
>>>>>
>>>>> V4.4 backport of spectre patches from Russell M. King's spectre branch.
>>>>> Most KVM patches are excluded. Patches not yet in upstream are excluded.
>>>>
>>>> I tested this patch set on top of stable 4.4 kernel, running on boards with
>>>> A9 and A15 based Hisilicon SoCs, didn't see boot regression and other function
>>>> regressions in our CI system,
>>>>
>>>> Tested-by: Hanjun Guo <hanjun.guo@xxxxxxxxxx>
>>>>
>>>> Since this patch set didn't include PSCI based hardening for arm32, so
>>>> bugfix 6282e916f774 ("ARM: 8809/1: proc-v7: fix Thumb annotation of
>>>> cpu_v7_hvc_switch_mm") is not needed for this patch set and this patch
>>>> set is in a good shape I think. So what's the plan for this patch set?
>>>
>>> Well, not having these patches means that a 32bit kernel won't be get
>>> any Spectre-v2 mitigation when run as a guest on an arm64 platform. It
>>> turns out that this is a pretty common setup among people building large
>>> pieces of SW, such as distributions.
>>
>> I almost miss this point, that makes sense to me :)
>>
>>>
>>> Not having KVM host mitigation on 32bit ARM is probably OK (let's face
>>> it, I'm the only user), but not mitigating it as a guest doesn't seem
>>> completely OK to me.
>>
>> We are working on a patch set which is backported from mainline to fix
>> ARM64 spectre-v1, spectre-v2 and SSBD for stable 4.4 kernel, and that
>> patch set (almost done) has PSCI patches which is needed by 32bit ARM,
>> so how about posting those ARM64 spectre fixes then backport all those
>> kvm patches for 32bit ARM spectre fix as well?
> I'm not sure I get what you mean by PSCI. PSCI is not involved in the
> Spectre-v2 mitigation, as we use a specially designed SMC call, relying
> on the SMCCC 1.1 infrastructure. Maybe it is what you're referring to here?
Sorry for the inexplicit, yes, it's the SMCCC 1.1 I'm referring here.
>
> Again, I don't think it is worth the hassle backporting the KVM patches.
> What I'd like to see is the guest (and bare metal) support code that
> uses the ARCH_WORKAROUND_1 SMCCC 1.1 infrastructure.
>
> I also don't think it is worth creating an artificial dependency between
> the two architectures. Yes, some patches are common (the SMCCC
> infrastructure), but that can be easily be solved at merge time. My vote
> would be for David to carry the relevant patches in this series.
Both are OK to me. David, could you please update this patch set
as Marc suggested?
Thanks
Hanjun
