kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Yanan Wang <wangyanan55@huawei.com>
Cc: kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [RFC PATCH v1 0/5] Enable CPU TTRem feature for stage-2
Date: Tue, 26 Jan 2021 14:18:21 +0000	[thread overview]
Message-ID: <cc15dabd0d7e0cb25d58101803e2c9a4@kernel.org> (raw)
In-Reply-To: <20210126134202.381996-1-wangyanan55@huawei.com>

Hi Yanan,

On 2021-01-26 13:41, Yanan Wang wrote:
> Hi all,
> This series enable CPU TTRem feature for stage-2 page table and a RFC 
> is sent
> for some comments, thanks.
> 
> The ARMv8.4 TTRem feature offers 3 levels of support when changing 
> block
> size without changing any other parameters that are listed as requiring 
> use
> of break-before-make. And I found that maybe we can use this feature to 
> make
> some improvement for stage-2 page table and the following explains what
> TTRem exactly does for the improvement.
> 
> If migration of a VM with hugepages is canceled midway, KVM will adjust 
> the
> stage-2 table mappings back to block mappings. We currently use BBM to 
> replace
> the table entry with a block entry. Take adjustment of 1G block mapping 
> as an
> example, with BBM procedures, we have to invalidate the old table entry 
> first,
> flush TLB and unmap the old table mappings, right before installing the 
> new
> block entry.

In all honesty, I think the amount of work that is getting added to
support this "migration cancelled mid-way" use case is getting out
of control.

This is adding a complexity and corner cases for a use case that
really shouldn't happen that often. And it is adding it at the worse
possible place, where we really should keep things as straightforward
as possible.

I would expect userspace to have a good enough knowledge of whether
the migration is likely to succeed, and not to attempt it if it is
likely to fail. And yes, it will fail sometimes. But it should be
so rare that adding this various stages of BBM support shouldn't be
that useful.

Or is there something else that I am missing?

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

      parent reply	other threads:[~2021-01-26 14:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26 13:41 [RFC PATCH v1 0/5] Enable CPU TTRem feature for stage-2 Yanan Wang
2021-01-26 13:41 ` [RFC PATCH v1 1/5] arm64: cpufeature: Detect the ARMv8.4 TTRem feature Yanan Wang
2021-01-26 13:41 ` [RFC PATCH v1 2/5] arm64: cpufeature: Add an API to get level of TTRem supported by hardware Yanan Wang
2021-01-26 13:42 ` [RFC PATCH v1 3/5] KVM: arm64: Support usage of TTRem in guest stage-2 translation Yanan Wang
2021-01-26 13:42 ` [RFC PATCH v1 4/5] KVM: arm64: Add handling of coalescing tables into a block mapping Yanan Wang
2021-01-26 13:42 ` [RFC PATCH v1 5/5] KVM: arm64: Adapt page-table code to new handling of coalescing tables Yanan Wang
2021-01-26 14:18 ` Marc Zyngier [this message]

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=cc15dabd0d7e0cb25d58101803e2c9a4@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wangyanan55@huawei.com \
    --cc=will@kernel.org \
    /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).