All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: "wangyanan (Y)" <wangyanan55@huawei.com>
Cc: jiangkunkun@huawei.com, Gavin Shan <gshan@redhat.com>,
	lushenming@huawei.com, Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	zhukeqian1@huawei.com, Quentin Perret <qperret@google.com>,
	wangjingyi11@huawei.com, linux-kernel@vger.kernel.org,
	yezengruan@huawei.com, James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org, yuzenghui@huawei.com,
	wanghaibin.wang@huawei.com, Will Deacon <will@kernel.org>,
	Julien Thierry <julien.thierry.kdev@gmail.com>
Subject: Re: [PATCH v2 0/3] Fix several bugs in KVM stage 2 translation
Date: Wed, 02 Dec 2020 12:23:11 +0000	[thread overview]
Message-ID: <616980dcddd5c7e832c1068f6fa91449@kernel.org> (raw)
In-Reply-To: <74540986-6197-34bc-cd53-850472091ee3@huawei.com>

Hi Yanan,

[...]

> BTW: there are two more things below that I want to talk about.
> 
> 1.  Recently, I have been focusing on the ARMv8.4-TTRem feature which
> is aimed at changing block size in stage 2 mapping.
> 
> I have a plan to implement this feature for stage 2 translation when
> splitting a block into tables or merging tables into a block.
> 
> This feature supports changing block size without performing
> *break-before-make*, which might have some improvement on performance.
> 
> What do you think about this?

It would be interesting if you can demonstrate some significant
performance improvements compared to the same workload with BBM.

I'm not completely convinced this would change much, given that
it is only when moving from a table to a block mapping that you
can elide BBM when the support level is 1 or 2. As far as I can
tell, this only happens in the "stop logging" case.

Is that something that happens often enough to justify the added
complexity? Having to handle TLB Conflict Abort is annoying, for
example.

> 2. Given that the issues we discussed before were found in practice
> when guest state changes from dirty logging to dirty logging canceled.
> 
> I could add a test file testing on this case to selftests/ or kvm unit
> tests/, if it's necessary.

That would be awesome, and I'd be very grateful if you did. It is the
second time we break this exact case, and having a reliable way to
verify it would definitely help.

Thanks,

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: "wangyanan (Y)" <wangyanan55@huawei.com>
Cc: Will Deacon <will@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Gavin Shan <gshan@redhat.com>,
	Quentin Perret <qperret@google.com>,
	wanghaibin.wang@huawei.com, yezengruan@huawei.com,
	zhukeqian1@huawei.com, yuzenghui@huawei.com,
	jiangkunkun@huawei.com, wangjingyi11@huawei.com,
	lushenming@huawei.com
Subject: Re: [PATCH v2 0/3] Fix several bugs in KVM stage 2 translation
Date: Wed, 02 Dec 2020 12:23:11 +0000	[thread overview]
Message-ID: <616980dcddd5c7e832c1068f6fa91449@kernel.org> (raw)
In-Reply-To: <74540986-6197-34bc-cd53-850472091ee3@huawei.com>

Hi Yanan,

[...]

> BTW: there are two more things below that I want to talk about.
> 
> 1.  Recently, I have been focusing on the ARMv8.4-TTRem feature which
> is aimed at changing block size in stage 2 mapping.
> 
> I have a plan to implement this feature for stage 2 translation when
> splitting a block into tables or merging tables into a block.
> 
> This feature supports changing block size without performing
> *break-before-make*, which might have some improvement on performance.
> 
> What do you think about this?

It would be interesting if you can demonstrate some significant
performance improvements compared to the same workload with BBM.

I'm not completely convinced this would change much, given that
it is only when moving from a table to a block mapping that you
can elide BBM when the support level is 1 or 2. As far as I can
tell, this only happens in the "stop logging" case.

Is that something that happens often enough to justify the added
complexity? Having to handle TLB Conflict Abort is annoying, for
example.

> 2. Given that the issues we discussed before were found in practice
> when guest state changes from dirty logging to dirty logging canceled.
> 
> I could add a test file testing on this case to selftests/ or kvm unit
> tests/, if it's necessary.

That would be awesome, and I'd be very grateful if you did. It is the
second time we break this exact case, and having a reliable way to
verify it would definitely help.

Thanks,

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

  reply	other threads:[~2020-12-02 12:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-01 20:10 [PATCH v2 0/3] Fix several bugs in KVM stage 2 translation Yanan Wang
2020-12-01 20:10 ` Yanan Wang
2020-12-01 20:10 ` [PATCH v2 1/3] KVM: arm64: Fix possible memory leak in kvm stage2 Yanan Wang
2020-12-01 20:10   ` Yanan Wang
2020-12-01 20:10 ` [PATCH v2 2/3] KVM: arm64: Fix handling of merging tables into a block entry Yanan Wang
2020-12-01 20:10   ` Yanan Wang
2020-12-01 20:10 ` [PATCH v2 3/3] KVM: arm64: Add usage of stage 2 fault lookup level in user_mem_abort() Yanan Wang
2020-12-01 20:10   ` Yanan Wang
2020-12-01 20:59 ` [PATCH v2 0/3] Fix several bugs in KVM stage 2 translation Will Deacon
2020-12-01 20:59   ` Will Deacon
2020-12-02 12:00   ` wangyanan (Y)
2020-12-02 12:00     ` wangyanan (Y)
2020-12-02 12:23     ` Marc Zyngier [this message]
2020-12-02 12:23       ` Marc Zyngier
2020-12-02 12:50       ` wangyanan (Y)
2020-12-02 12:50         ` wangyanan (Y)
2020-12-02 12:24 ` Marc Zyngier
2020-12-02 12:24   ` Marc Zyngier

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=616980dcddd5c7e832c1068f6fa91449@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=gshan@redhat.com \
    --cc=james.morse@arm.com \
    --cc=jiangkunkun@huawei.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lushenming@huawei.com \
    --cc=qperret@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=wanghaibin.wang@huawei.com \
    --cc=wangjingyi11@huawei.com \
    --cc=wangyanan55@huawei.com \
    --cc=will@kernel.org \
    --cc=yezengruan@huawei.com \
    --cc=yuzenghui@huawei.com \
    --cc=zhukeqian1@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.