All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 06/21] KVM: arm64: Add support for stage-2 map()/unmap() in generic page-table
Date: Thu, 10 Sep 2020 14:55:52 +0100	[thread overview]
Message-ID: <ea9677c4-e6c6-6a2a-725b-df86adeefd94@arm.com> (raw)
In-Reply-To: <20200910123404.GA18100@willie-the-truck>

Hi Will,

On 9/10/20 1:34 PM, Will Deacon wrote:
> On Thu, Sep 10, 2020 at 12:20:42PM +0100, Alexandru Elisei wrote:
>> On 9/7/20 4:23 PM, Will Deacon wrote:
>>> +static int stage2_map_walk_table_post(u64 addr, u64 end, u32 level,
>>> +				      kvm_pte_t *ptep,
>>> +				      struct stage2_map_data *data)
>>> +{
>>> +	int ret = 0;
>>> +
>>> +	if (!data->anchor)
>>> +		return 0;
>>> +
>>> +	free_page((unsigned long)kvm_pte_follow(*ptep));
>>> +	put_page(virt_to_page(ptep));
>>> +
>>> +	if (data->anchor == ptep) {
>>> +		data->anchor = NULL;
>>> +		ret = stage2_map_walk_leaf(addr, end, level, ptep, data);
>>> +	}
>> I had another look at this function. If we're back to the anchor entry, then that
>> means that we know from the pre-order visitor that 1. the mapping is supported at
>> this level and 2. that the pte was invalidated. This means that
>> kvm_set_valid_leaf_pte() will succeed in changing the entry. How about instead of
>> calling stage2_map_walk_leaf() -> stage2_map_walker_try_leaf() ->
>> kvm_set_valid_leaf_pte() we call kvm_set_valid_leaf_pte() directly, followed by
>> get_page(virt_to_page(ptep)? It would make the code a lot easier to follow
>> (stage2_map_walk_leaf() is pretty complicated, imo, but that can't really be
>> avoided), and also slightly faster.
> I'm not sure I agree. I would consider kvm_set_valid_leaf_pte() to be lower
> level, and not the right function to be calling here. Rather,
> stage2_map_walk_leaf() is what would have been called if we hadn't spotted
> the potential for a block mapping anyway, so I much prefer that symmetry. It
> also means that if stage2_map_walk_leaf() grows some extra logic in future
> that we need to take into account here, we won't miss anything.

Sure, that makes sense.

Thanks,
Alex
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Gavin Shan <gshan@redhat.com>,
	Suzuki Poulose <suzuki.poulose@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	Quentin Perret <qperret@google.com>,
	James Morse <james.morse@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 06/21] KVM: arm64: Add support for stage-2 map()/unmap() in generic page-table
Date: Thu, 10 Sep 2020 14:55:52 +0100	[thread overview]
Message-ID: <ea9677c4-e6c6-6a2a-725b-df86adeefd94@arm.com> (raw)
In-Reply-To: <20200910123404.GA18100@willie-the-truck>

Hi Will,

On 9/10/20 1:34 PM, Will Deacon wrote:
> On Thu, Sep 10, 2020 at 12:20:42PM +0100, Alexandru Elisei wrote:
>> On 9/7/20 4:23 PM, Will Deacon wrote:
>>> +static int stage2_map_walk_table_post(u64 addr, u64 end, u32 level,
>>> +				      kvm_pte_t *ptep,
>>> +				      struct stage2_map_data *data)
>>> +{
>>> +	int ret = 0;
>>> +
>>> +	if (!data->anchor)
>>> +		return 0;
>>> +
>>> +	free_page((unsigned long)kvm_pte_follow(*ptep));
>>> +	put_page(virt_to_page(ptep));
>>> +
>>> +	if (data->anchor == ptep) {
>>> +		data->anchor = NULL;
>>> +		ret = stage2_map_walk_leaf(addr, end, level, ptep, data);
>>> +	}
>> I had another look at this function. If we're back to the anchor entry, then that
>> means that we know from the pre-order visitor that 1. the mapping is supported at
>> this level and 2. that the pte was invalidated. This means that
>> kvm_set_valid_leaf_pte() will succeed in changing the entry. How about instead of
>> calling stage2_map_walk_leaf() -> stage2_map_walker_try_leaf() ->
>> kvm_set_valid_leaf_pte() we call kvm_set_valid_leaf_pte() directly, followed by
>> get_page(virt_to_page(ptep)? It would make the code a lot easier to follow
>> (stage2_map_walk_leaf() is pretty complicated, imo, but that can't really be
>> avoided), and also slightly faster.
> I'm not sure I agree. I would consider kvm_set_valid_leaf_pte() to be lower
> level, and not the right function to be calling here. Rather,
> stage2_map_walk_leaf() is what would have been called if we hadn't spotted
> the potential for a block mapping anyway, so I much prefer that symmetry. It
> also means that if stage2_map_walk_leaf() grows some extra logic in future
> that we need to take into account here, we won't miss anything.

Sure, that makes sense.

Thanks,
Alex

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

  reply	other threads:[~2020-09-10 13:54 UTC|newest]

Thread overview: 104+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-07 15:23 [PATCH v4 00/21] KVM: arm64: Rewrite page-table code and fault handling Will Deacon
2020-09-07 15:23 ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 01/21] KVM: arm64: Remove kvm_mmu_free_memory_caches() Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 02/21] KVM: arm64: Add stand-alone page-table walker infrastructure Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-08  0:03   ` Gavin Shan
2020-09-08  0:03     ` Gavin Shan
2020-09-10 10:57     ` Will Deacon
2020-09-10 10:57       ` Will Deacon
2020-09-09 15:29   ` Alexandru Elisei
2020-09-09 15:29     ` Alexandru Elisei
2020-09-10 12:37     ` Will Deacon
2020-09-10 12:37       ` Will Deacon
2020-09-10 14:21       ` Andrew Scull
2020-09-10 14:21         ` Andrew Scull
2020-09-11 10:15         ` Will Deacon
2020-09-11 10:15           ` Will Deacon
2020-09-11 11:22           ` Andrew Scull
2020-09-11 11:22             ` Andrew Scull
2020-09-07 15:23 ` [PATCH v4 03/21] KVM: arm64: Add support for creating kernel-agnostic stage-1 page tables Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-08  1:09   ` Gavin Shan
2020-09-08  1:09     ` Gavin Shan
2020-09-07 15:23 ` [PATCH v4 04/21] KVM: arm64: Use generic allocator for hyp stage-1 page-tables Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-08  1:03   ` Gavin Shan
2020-09-08  1:03     ` Gavin Shan
2020-09-07 15:23 ` [PATCH v4 05/21] KVM: arm64: Add support for creating kernel-agnostic stage-2 page tables Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 06/21] KVM: arm64: Add support for stage-2 map()/unmap() in generic page-table Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-10 11:20   ` Alexandru Elisei
2020-09-10 11:20     ` Alexandru Elisei
2020-09-10 12:34     ` Will Deacon
2020-09-10 12:34       ` Will Deacon
2020-09-10 13:55       ` Alexandru Elisei [this message]
2020-09-10 13:55         ` Alexandru Elisei
2020-09-07 15:23 ` [PATCH v4 07/21] KVM: arm64: Convert kvm_phys_addr_ioremap() to generic page-table API Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 08/21] KVM: arm64: Convert kvm_set_spte_hva() " Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 09/21] KVM: arm64: Convert unmap_stage2_range() " Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 10/21] KVM: arm64: Add support for stage-2 page-aging in generic page-table Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-08 15:30   ` Alexandru Elisei
2020-09-08 15:30     ` Alexandru Elisei
2020-09-10 12:42     ` Will Deacon
2020-09-10 12:42       ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 11/21] KVM: arm64: Convert page-aging and access faults to generic page-table API Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-08 15:39   ` Alexandru Elisei
2020-09-08 15:39     ` Alexandru Elisei
2020-09-07 15:23 ` [PATCH v4 12/21] KVM: arm64: Add support for stage-2 write-protect in generic page-table Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 13/21] KVM: arm64: Convert write-protect operation to generic page-table API Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 14/21] KVM: arm64: Add support for stage-2 cache flushing in generic page-table Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 15/21] KVM: arm64: Convert memslot cache-flushing code to generic page-table API Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 16/21] KVM: arm64: Add support for relaxing stage-2 perms in generic page-table code Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-08 16:37   ` Alexandru Elisei
2020-09-08 16:37     ` Alexandru Elisei
2020-09-07 15:23 ` [PATCH v4 17/21] KVM: arm64: Convert user_mem_abort() to generic page-table API Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-09 14:20   ` Alexandru Elisei
2020-09-09 14:20     ` Alexandru Elisei
2020-09-09 17:12     ` Marc Zyngier
2020-09-09 17:12       ` Marc Zyngier
2020-09-10 10:51       ` Will Deacon
2020-09-10 10:51         ` Will Deacon
2020-09-10 10:58         ` Marc Zyngier
2020-09-10 10:58           ` Marc Zyngier
2020-09-10 13:10         ` Alexandru Elisei
2020-09-10 13:10           ` Alexandru Elisei
2020-09-10 13:20       ` Alexandru Elisei
2020-09-10 13:20         ` Alexandru Elisei
2020-09-07 15:23 ` [PATCH v4 18/21] KVM: arm64: Check the pgt instead of the pgd when modifying page-table Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 19/21] KVM: arm64: Remove unused page-table code Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-08 10:33   ` Marc Zyngier
2020-09-08 10:33     ` Marc Zyngier
2020-09-10 10:54     ` Will Deacon
2020-09-10 10:54       ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 20/21] KVM: arm64: Remove unused 'pgd' field from 'struct kvm_s2_mmu' Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-07 15:23 ` [PATCH v4 21/21] KVM: arm64: Don't constrain maximum IPA size based on host configuration Will Deacon
2020-09-07 15:23   ` Will Deacon
2020-09-09 14:53   ` Alexandru Elisei
2020-09-09 14:53     ` Alexandru Elisei
2020-09-07 17:16 ` [PATCH v4 00/21] KVM: arm64: Rewrite page-table code and fault handling Marc Zyngier
2020-09-07 17:16   ` Marc Zyngier
2020-09-07 17:31   ` Will Deacon
2020-09-07 17:31     ` Will Deacon
2020-09-10  4:06 ` Gavin Shan
2020-09-10  4:06   ` Gavin Shan
2020-09-10  4:11   ` Gavin Shan
2020-09-10  4:11     ` Gavin Shan
2020-09-10 10:58   ` Will Deacon
2020-09-10 10:58     ` Will Deacon

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=ea9677c4-e6c6-6a2a-725b-df86adeefd94@arm.com \
    --to=alexandru.elisei@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --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 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.