On 03/02/2018 06:29 PM, Marc Zyngier wrote:
> On Fri, 02 Mar 2018 09:02:32 +0000,
> Alex Shi wrote:
>> On 03/02/2018 12:46 AM, Greg KH wrote:
>>> On Thu, Mar 01, 2018 at 08:53:37PM +0800, Alex Shi wrote:
>>>> Hi All,
>>>> Resent without non-upstream patches.
>>>> This backport patchset fixed the spectre issue, it's original branch:
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti
>>>> A few dependency or fixingpatches are also picked up, if they are necessary
>>>>  and no functional changes.
>>>> No bug found from kernelci.org and lkft testing. It also could be gotten 
>>>> from:
>>>> git://git.linaro.org/kernel/linux-linaro-stable.git 
>>>> v4.9-spectre-upstream-only
>>> Also, how did you test, what platforms did you test, and did you test
>>> that this actually did fix the spectre issue on your platforms?  If so,
>>> what test did you use?
>> On the kernelci, there are 18 kinds of platoforms with different
>> configure tested booting, detailed info is here:
>> https://kernelci.org/boot/all/job/lsk/branch/linux-linaro-lsk-v4.9-test/kernel/lsk-v4.9-17.03-4844-g6f782cff6edb/
>> I also tested the qemu boot on hikey620. and normal boot on
> Did you try QEMU in conjunction with KVM? Or just in emulation?

Many many thanks for response!

Yes, I tried both of type boot with or w/o KVM. Both works.

>> hikey620/db410c/junor2. The other testing include the LKFT testing which
>> is reported by email, same as test for LTS. None of testing show
>> regressions.
>> As testing the spectre bug fix, that's a good question. I also asked
>> this question to original patch authors, like Marc. They said they just
>> figure out these patches could block spectre or meltdown issue. From my
>> side, I just reproduced the process internal spectre. But all fix on arm
>> can not resolve the user space internal spectre. It can block from user
>> to kernel or kernel to user spectre according the code purose. So I
>> believe these patch could do their job. And arm cpu would drop the
>> spectre branches if it has 20+ 'nop' instructions...
> What are you talking about? What's that story about NOPs? There are
> clear mitigation guidelines for ARM cores, please don't make things
> up.

Oops, sorry for misunderstanding! what's I meaning is, among many kind
of solution to mitigation issues, like ATF changes, compiler change, BT
changes, 'nop' is interesting for me. Sorry for bad expression.


Reply via email to