linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wei Xu <xuwei5@hisilicon.com>
To: Will Deacon <will.deacon@arm.com>
Cc: James Morse <james.morse@arm.com>, <mark.rutland@arm.com>,
	<catalin.marinas@arm.com>, Linuxarm <linuxarm@huawei.com>,
	Zhangyi ac <zhangyi.ac@huawei.com>, <suzuki.poulose@arm.com>,
	<marc.zyngier@arm.com>,
	"Xiongfanggou (James)" <james.xiong@huawei.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <dave.martin@arm.com>,
	"Liyuan (Larry, Turing Solution)" <Larry.T@huawei.com>,
	<libeijian@hisilicon.com>, <zhangxiquan@hisilicon.com>,
	<wxf.wang@hisilicon.com>, <dingshuai1@huawei.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	"Liguozhu (Kenneth)" <liguozhu@hisilicon.com>,
	<zhangxiquan@hisilicon.com>, <wxf.wang@hisilicon.com>,
	Hanjun Guo <guohanjun@huawei.com>, <dingshuai1@huawei.com>
Subject: Re: KVM guest sometimes failed to boot because of kernel stack overflow if KPTI is enabled on a hisilicon ARM64 platform.
Date: Thu, 28 Jun 2018 15:50:40 +0100	[thread overview]
Message-ID: <5B34F5C0.9090001@hisilicon.com> (raw)
In-Reply-To: <20180627132826.GB30631@arm.com>

Hi Will,

On 2018/6/27 14:28, Will Deacon wrote:
> On Wed, Jun 27, 2018 at 02:22:03PM +0100, Wei Xu wrote:
>> On 2018/6/26 18:47, Will Deacon wrote:
>>> If you look at the __idmap_kpti_put_pgtable_ent_ng asm macro, can you try
>>> replacing:
>>>
>>> 	dc      civac, cur_\()\type\()p
>>>
>>> with:
>>>
>>> 	dc      ivac, cur_\()\type\()p
>>>
>>> please? Only do this for the guest kernel, not the host. KVM will upgrade
>>> the clean to a clean+invalidate, so it's interesting to see if this has
>>> an effect on the behaviour.
>>
>> Only changed the guest kernel, the guest still failed to boot and the log
>> is same with the last mail.
>>
>> But if I changed to cvac as below for the guest, it is kind of stable.
>> 	dc      cvac, cur_\()\type\()p
>>
>> I have synced with our SoC guys about this and hope we can find the reason.
>> Do you have any more suggestion?
> 
> Unfortunately, not. It looks like somehow clean+invalidate is behaving
> just as an invalidate, and we're corrupting the page table as a result.
> 
> Hopefully the SoC guys will figure it out.

After replaced the dmb with dsb in both __idmap_kpti_get_pgtable_ent and
__idmap_kpti_put_pgtable_ent_ng, we tested 20 times and we can not reproduce
the issue.
Today we will continue to do the stress testing and will update the result tomorrow.

The dsb in __idmap_kpti_get_pgtable_ent is to make sure the dc has been done and
the following ldr can get the latest data.

The dsb in __idmap_kpti_put_pgtable_ent_ng is to make sure the str will be done
before dc. Although dmb can guarantee the order of the str and dc on the L2 cache,
dmb can not guarantee the order on the bus.

How do you think about it?
Thanks!

----

diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 03646e6..bb767ea 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -209,7 +209,7 @@ ENDPROC(idmap_cpu_replace_ttbr1)

        .macro  __idmap_kpti_get_pgtable_ent, type
        dc      cvac, cur_\()\type\()p          // Ensure any existing dirty
-       dmb     sy                              // lines are written back before
+       dsb     sy                              // lines are written back before
        ldr     \type, [cur_\()\type\()p]       // loading the entry
        tbz     \type, #0, skip_\()\type        // Skip invalid and
        tbnz    \type, #11, skip_\()\type       // non-global entries
@@ -218,8 +218,9 @@ ENDPROC(idmap_cpu_replace_ttbr1)
        .macro __idmap_kpti_put_pgtable_ent_ng, type
        orr     \type, \type, #PTE_NG           // Same bit for blocks and pages
        str     \type, [cur_\()\type\()p]       // Update the entry and ensure
-       dmb     sy                              // that it is visible to all
+       dsb     sy                              // that it is visible to all
        dc      civac, cur_\()\type\()p         // CPUs. 	


Best Regards,
Wei

> 
> Will
> 
> .
> 


  parent reply	other threads:[~2018-06-27 19:48 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-20 14:18 KVM guest sometimes failed to boot because of kernel stack overflow if KPTI is enabled on a hisilicon ARM64 platform Wei Xu
2018-06-20 14:42 ` Will Deacon
2018-06-20 15:52   ` Wei Xu
2018-06-20 15:54     ` James Morse
2018-06-20 16:25       ` Wei Xu
2018-06-20 16:28         ` Will Deacon
2018-06-20 16:33           ` Wei Xu
2018-06-21  8:38         ` James Morse
2018-06-21  9:00           ` Marc Zyngier
2018-06-21  9:18           ` Will Deacon
2018-06-21 10:14             ` Wei Xu
2018-06-21 10:54               ` Will Deacon
2018-06-22  8:33                 ` Wei Xu
2018-06-22  9:23                   ` Will Deacon
2018-06-22 10:45                     ` Wei Xu
2018-06-22 11:16                       ` Will Deacon
2018-06-22 13:18                         ` Wei Xu
2018-06-22 13:31                           ` Will Deacon
2018-06-22 13:46                             ` Wei Xu
2018-06-22 14:43                               ` Will Deacon
2018-06-22 15:26                                 ` Wei Xu
2018-06-22 14:28                           ` Mark Rutland
2018-06-22 15:28                             ` Wei Xu
2018-06-22 15:41                               ` Will Deacon
2018-06-22 16:02                                 ` Wei Xu
2018-06-21  9:20           ` Wei Xu
2018-06-26 17:16             ` Wei Xu
2018-06-26 17:47               ` Will Deacon
2018-06-27  8:39                 ` James Morse
2018-06-27 13:26                   ` Wei Xu
2018-06-28  8:45                     ` James Morse
2018-06-28 10:20                       ` Wei Xu
2018-06-27 13:22                 ` Wei Xu
2018-06-27 13:28                   ` Will Deacon
2018-06-27 13:32                     ` Wei Xu
2018-06-28 14:50                     ` Wei Xu [this message]
2018-06-28 15:34                       ` Mark Rutland
     [not found]                         ` <etPan.5b3507f7.914aa16.1d6b@localhost>
2018-06-28 16:24                           ` 答复: " Mark Rutland
2018-06-29  9:59                             ` Mark Rutland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5B34F5C0.9090001@hisilicon.com \
    --to=xuwei5@hisilicon.com \
    --cc=Larry.T@huawei.com \
    --cc=catalin.marinas@arm.com \
    --cc=dave.martin@arm.com \
    --cc=dingshuai1@huawei.com \
    --cc=guohanjun@huawei.com \
    --cc=james.morse@arm.com \
    --cc=james.xiong@huawei.com \
    --cc=libeijian@hisilicon.com \
    --cc=liguozhu@hisilicon.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will.deacon@arm.com \
    --cc=wxf.wang@hisilicon.com \
    --cc=zhangxiquan@hisilicon.com \
    --cc=zhangyi.ac@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).