mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: Wei Xu <xuwei5@hisilicon.com>
Cc: Will Deacon <will.deacon@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
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 09:45:56 +0100	[thread overview]
Message-ID: <9549e15d-4ec6-8dd3-2237-b6c9b52fc816@arm.com> (raw)
In-Reply-To: <5B339068.5020304@hisilicon.com>

Hi Wei,

On 27/06/18 14:26, Wei Xu wrote:
> Sorry, I should highlight that I have only updated the default value
> of CONFIG_NR_CPUS by menuconfig in the previous mail.
> That is why it showed dirty.

(menuconfig changes don't show up like this)


More than 64 CPUs ... Is this system running more VMs than it has VMIDs? Too-few
VMIDs does work with KVM, its just going to trigger rollover frequently.

Just to check, what kernel version is the host running? Does it have commit
f0cf47d939d0 ("KVM: arm/arm64: Close VMID generation race")
(looks like that went in as a fix for v4.17-rc3)

Are you running (lots) of other VMs whenever this happens? Do they have multiple
vcpus? (I'm thinking of the scenario in that patch's description)

Is the host system otherwise idle when this happens?
(If not, can you reproduce the issue without exhausting the VMIDs?)


It may be that writing back the page-table entries with the MMU off, and
changing the cache maintenance are just changing the timing of something else.


Thanks,

James

  reply	other threads:[~2018-06-28  8:46 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-20 14:18 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 [this message]
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
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=9549e15d-4ec6-8dd3-2237-b6c9b52fc816@arm.com \
    --to=james.morse@arm.com \
    --cc=Larry.T@huawei.com \
    --cc=catalin.marinas@arm.com \
    --cc=dave.martin@arm.com \
    --cc=james.xiong@huawei.com \
    --cc=libeijian@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=xuwei5@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

all inboxes | Powered by JetHome®