All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Perret <qperret@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: james.morse@arm.com, alexandru.elisei@arm.com,
	suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	ardb@kernel.org, qwandor@google.com, tabba@google.com,
	dbrazdil@google.com, kernel-team@android.com
Subject: Re: [PATCH v2 04/16] KVM: arm64: Optimize host memory aborts
Date: Mon, 26 Jul 2021 14:13:06 +0100	[thread overview]
Message-ID: <YP604j6B1pkhAnT1@google.com> (raw)
In-Reply-To: <87pmv5e529.wl-maz@kernel.org>

On Monday 26 Jul 2021 at 11:35:10 (+0100), Marc Zyngier wrote:
> On Mon, 26 Jul 2021 10:28:53 +0100,
> Quentin Perret <qperret@google.com> wrote:
> > +static int host_stage2_find_range(u64 addr, struct kvm_mem_range *range)
> 
> nit: I find 'find_range' a bit odd. We already have found a
> range. We're just trying to narrow it down to something that fits in a
> single block mapping. How about 'host_stage2_adjust_range'?

Ack.

> > +{
> > +	u64 granule, start, end;
> > +	kvm_pte_t pte;
> > +	u32 level;
> > +	int ret;
> > +
> > +	ret = kvm_pgtable_get_leaf(&host_kvm.pgt, addr, &pte, &level);
> > +	if (ret)
> > +		return ret;
> > +
> > +	if (kvm_pte_valid(pte))
> > +		return -EAGAIN;
> > +
> > +	if (pte)
> > +		return -EPERM;
> > +
> > +	do {
> > +		granule = kvm_granule_size(level);
> > +		start = ALIGN_DOWN(addr, granule);
> > +		end = start + granule;
> > +		level++;
> > +	} while ((level < KVM_PGTABLE_MAX_LEVELS) &&
> > +			(!kvm_level_supports_block_mapping(level) ||
> > +			 start < range->start || range->end < end));
> > +
> 
> This expression does my head in. You are trying to find the largest
> block mapping that entirely fits in range, right? Can we just express
> that directly (with a global negation for the purpose of the loop)?
> 
> 	do {
> 		[...]
> 	} while (level < KVM_PGTABLE_MAX_LEVELS &&
> 		 !(kvm_level_supports_block_mapping(level) &&
> 		   start >= range->start &&
> 		   end <= range->end));
> 
> I personally find this much more readable, because it expresses the
> condition we are looking for rather than a lot of conditions forcing
> us to continue.
> 
> You could also use a kvm_mem_range for the iteration, and add a helper
> that checks for the inclusion.

Something like this (untested)?

diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 75273166d2c5..07d228163090 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -234,9 +234,15 @@ static inline int __host_stage2_idmap(u64 start, u64 end,
                __ret;                                                  \
         })

+static inline bool range_included(struct kvm_mem_range *child,
+                                 struct kvm_mem_range *parent)
+{
+       return parent->start <= child->start && child->end <= parent->end;
+}
+
 static int host_stage2_find_range(u64 addr, struct kvm_mem_range *range)
 {
-       u64 granule, start, end;
+       struct kvm_mem_range cur;
        kvm_pte_t pte;
        u32 level;
        int ret;
@@ -252,16 +258,15 @@ static int host_stage2_find_range(u64 addr, struct kvm_mem_range *range)
                return -EPERM;

        do {
-               granule = kvm_granule_size(level);
-               start = ALIGN_DOWN(addr, granule);
-               end = start + granule;
+               u64 granule = kvm_granule_size(level);
+               cur.start = ALIGN_DOWN(addr, granule);
+               cur.end = cur.start + granule;
                level++;
        } while ((level < KVM_PGTABLE_MAX_LEVELS) &&
-                       (!kvm_level_supports_block_mapping(level) ||
-                        start < range->start || range->end < end));
+                       !(kvm_level_supports_block_mapping(level) &&
+                         range_included(&cur, parent)));

-       range->start = start;
-       range->end = end;
+       *range = cur;

        return 0;
 }

WARNING: multiple messages have this Message-ID (diff)
From: Quentin Perret <qperret@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kernel-team@android.com, qwandor@google.com, will@kernel.org,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 04/16] KVM: arm64: Optimize host memory aborts
Date: Mon, 26 Jul 2021 14:13:06 +0100	[thread overview]
Message-ID: <YP604j6B1pkhAnT1@google.com> (raw)
In-Reply-To: <87pmv5e529.wl-maz@kernel.org>

On Monday 26 Jul 2021 at 11:35:10 (+0100), Marc Zyngier wrote:
> On Mon, 26 Jul 2021 10:28:53 +0100,
> Quentin Perret <qperret@google.com> wrote:
> > +static int host_stage2_find_range(u64 addr, struct kvm_mem_range *range)
> 
> nit: I find 'find_range' a bit odd. We already have found a
> range. We're just trying to narrow it down to something that fits in a
> single block mapping. How about 'host_stage2_adjust_range'?

Ack.

> > +{
> > +	u64 granule, start, end;
> > +	kvm_pte_t pte;
> > +	u32 level;
> > +	int ret;
> > +
> > +	ret = kvm_pgtable_get_leaf(&host_kvm.pgt, addr, &pte, &level);
> > +	if (ret)
> > +		return ret;
> > +
> > +	if (kvm_pte_valid(pte))
> > +		return -EAGAIN;
> > +
> > +	if (pte)
> > +		return -EPERM;
> > +
> > +	do {
> > +		granule = kvm_granule_size(level);
> > +		start = ALIGN_DOWN(addr, granule);
> > +		end = start + granule;
> > +		level++;
> > +	} while ((level < KVM_PGTABLE_MAX_LEVELS) &&
> > +			(!kvm_level_supports_block_mapping(level) ||
> > +			 start < range->start || range->end < end));
> > +
> 
> This expression does my head in. You are trying to find the largest
> block mapping that entirely fits in range, right? Can we just express
> that directly (with a global negation for the purpose of the loop)?
> 
> 	do {
> 		[...]
> 	} while (level < KVM_PGTABLE_MAX_LEVELS &&
> 		 !(kvm_level_supports_block_mapping(level) &&
> 		   start >= range->start &&
> 		   end <= range->end));
> 
> I personally find this much more readable, because it expresses the
> condition we are looking for rather than a lot of conditions forcing
> us to continue.
> 
> You could also use a kvm_mem_range for the iteration, and add a helper
> that checks for the inclusion.

Something like this (untested)?

diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 75273166d2c5..07d228163090 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -234,9 +234,15 @@ static inline int __host_stage2_idmap(u64 start, u64 end,
                __ret;                                                  \
         })

+static inline bool range_included(struct kvm_mem_range *child,
+                                 struct kvm_mem_range *parent)
+{
+       return parent->start <= child->start && child->end <= parent->end;
+}
+
 static int host_stage2_find_range(u64 addr, struct kvm_mem_range *range)
 {
-       u64 granule, start, end;
+       struct kvm_mem_range cur;
        kvm_pte_t pte;
        u32 level;
        int ret;
@@ -252,16 +258,15 @@ static int host_stage2_find_range(u64 addr, struct kvm_mem_range *range)
                return -EPERM;

        do {
-               granule = kvm_granule_size(level);
-               start = ALIGN_DOWN(addr, granule);
-               end = start + granule;
+               u64 granule = kvm_granule_size(level);
+               cur.start = ALIGN_DOWN(addr, granule);
+               cur.end = cur.start + granule;
                level++;
        } while ((level < KVM_PGTABLE_MAX_LEVELS) &&
-                       (!kvm_level_supports_block_mapping(level) ||
-                        start < range->start || range->end < end));
+                       !(kvm_level_supports_block_mapping(level) &&
+                         range_included(&cur, parent)));

-       range->start = start;
-       range->end = end;
+       *range = cur;

        return 0;
 }
_______________________________________________
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: Quentin Perret <qperret@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: james.morse@arm.com, alexandru.elisei@arm.com,
	suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	ardb@kernel.org, qwandor@google.com, tabba@google.com,
	dbrazdil@google.com, kernel-team@android.com
Subject: Re: [PATCH v2 04/16] KVM: arm64: Optimize host memory aborts
Date: Mon, 26 Jul 2021 14:13:06 +0100	[thread overview]
Message-ID: <YP604j6B1pkhAnT1@google.com> (raw)
In-Reply-To: <87pmv5e529.wl-maz@kernel.org>

On Monday 26 Jul 2021 at 11:35:10 (+0100), Marc Zyngier wrote:
> On Mon, 26 Jul 2021 10:28:53 +0100,
> Quentin Perret <qperret@google.com> wrote:
> > +static int host_stage2_find_range(u64 addr, struct kvm_mem_range *range)
> 
> nit: I find 'find_range' a bit odd. We already have found a
> range. We're just trying to narrow it down to something that fits in a
> single block mapping. How about 'host_stage2_adjust_range'?

Ack.

> > +{
> > +	u64 granule, start, end;
> > +	kvm_pte_t pte;
> > +	u32 level;
> > +	int ret;
> > +
> > +	ret = kvm_pgtable_get_leaf(&host_kvm.pgt, addr, &pte, &level);
> > +	if (ret)
> > +		return ret;
> > +
> > +	if (kvm_pte_valid(pte))
> > +		return -EAGAIN;
> > +
> > +	if (pte)
> > +		return -EPERM;
> > +
> > +	do {
> > +		granule = kvm_granule_size(level);
> > +		start = ALIGN_DOWN(addr, granule);
> > +		end = start + granule;
> > +		level++;
> > +	} while ((level < KVM_PGTABLE_MAX_LEVELS) &&
> > +			(!kvm_level_supports_block_mapping(level) ||
> > +			 start < range->start || range->end < end));
> > +
> 
> This expression does my head in. You are trying to find the largest
> block mapping that entirely fits in range, right? Can we just express
> that directly (with a global negation for the purpose of the loop)?
> 
> 	do {
> 		[...]
> 	} while (level < KVM_PGTABLE_MAX_LEVELS &&
> 		 !(kvm_level_supports_block_mapping(level) &&
> 		   start >= range->start &&
> 		   end <= range->end));
> 
> I personally find this much more readable, because it expresses the
> condition we are looking for rather than a lot of conditions forcing
> us to continue.
> 
> You could also use a kvm_mem_range for the iteration, and add a helper
> that checks for the inclusion.

Something like this (untested)?

diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 75273166d2c5..07d228163090 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -234,9 +234,15 @@ static inline int __host_stage2_idmap(u64 start, u64 end,
                __ret;                                                  \
         })

+static inline bool range_included(struct kvm_mem_range *child,
+                                 struct kvm_mem_range *parent)
+{
+       return parent->start <= child->start && child->end <= parent->end;
+}
+
 static int host_stage2_find_range(u64 addr, struct kvm_mem_range *range)
 {
-       u64 granule, start, end;
+       struct kvm_mem_range cur;
        kvm_pte_t pte;
        u32 level;
        int ret;
@@ -252,16 +258,15 @@ static int host_stage2_find_range(u64 addr, struct kvm_mem_range *range)
                return -EPERM;

        do {
-               granule = kvm_granule_size(level);
-               start = ALIGN_DOWN(addr, granule);
-               end = start + granule;
+               u64 granule = kvm_granule_size(level);
+               cur.start = ALIGN_DOWN(addr, granule);
+               cur.end = cur.start + granule;
                level++;
        } while ((level < KVM_PGTABLE_MAX_LEVELS) &&
-                       (!kvm_level_supports_block_mapping(level) ||
-                        start < range->start || range->end < end));
+                       !(kvm_level_supports_block_mapping(level) &&
+                         range_included(&cur, parent)));

-       range->start = start;
-       range->end = end;
+       *range = cur;

        return 0;
 }

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

  reply	other threads:[~2021-07-26 13:13 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26  9:28 [PATCH v2 00/16] Track shared pages at EL2 in protected mode Quentin Perret
2021-07-26  9:28 ` Quentin Perret
2021-07-26  9:28 ` Quentin Perret
2021-07-26  9:28 ` [PATCH v2 01/16] KVM: arm64: Introduce helper to retrieve a PTE and its level Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28 ` [PATCH v2 02/16] KVM: arm64: Provide the host_stage2_try() helper macro Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28 ` [PATCH v2 03/16] KVM: arm64: Expose page-table helpers Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28 ` [PATCH v2 04/16] KVM: arm64: Optimize host memory aborts Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26 10:35   ` Marc Zyngier
2021-07-26 10:35     ` Marc Zyngier
2021-07-26 10:35     ` Marc Zyngier
2021-07-26 13:13     ` Quentin Perret [this message]
2021-07-26 13:13       ` Quentin Perret
2021-07-26 13:13       ` Quentin Perret
2021-07-26 13:24       ` Marc Zyngier
2021-07-26 13:24         ` Marc Zyngier
2021-07-26 13:24         ` Marc Zyngier
2021-07-26  9:28 ` [PATCH v2 05/16] KVM: arm64: Rename KVM_PTE_LEAF_ATTR_S2_IGNORED Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28 ` [PATCH v2 06/16] KVM: arm64: Don't overwrite software bits with owner id Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28 ` [PATCH v2 07/16] KVM: arm64: Tolerate re-creating hyp mappings to set software bits Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28 ` [PATCH v2 08/16] KVM: arm64: Enable forcing page-level stage-2 mappings Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28 ` [PATCH v2 09/16] KVM: arm64: Allow populating software bits Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28 ` [PATCH v2 10/16] KVM: arm64: Add helpers to tag shared pages in SW bits Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:28   ` Quentin Perret
2021-07-26  9:29 ` [PATCH v2 11/16] KVM: arm64: Introduce and export host_stage2_idmap_locked() Quentin Perret
2021-07-26  9:29   ` Quentin Perret
2021-07-26  9:29   ` Quentin Perret
2021-07-26  9:29 ` [PATCH v2 12/16] KVM: arm64: Mark host bss and rodata section as shared Quentin Perret
2021-07-26  9:29   ` Quentin Perret
2021-07-26  9:29   ` Quentin Perret
2021-07-28 12:14   ` Quentin Perret
2021-07-28 12:14     ` Quentin Perret
2021-07-28 12:14     ` Quentin Perret
2021-07-26  9:29 ` [PATCH v2 13/16] KVM: arm64: Enable retrieving protections attributes of PTEs Quentin Perret
2021-07-26  9:29   ` Quentin Perret
2021-07-26  9:29   ` Quentin Perret
2021-07-26  9:29 ` [PATCH v2 14/16] KVM: arm64: Refactor protected nVHE stage-1 locking Quentin Perret
2021-07-26  9:29   ` Quentin Perret
2021-07-26  9:29   ` Quentin Perret
2021-07-26  9:29 ` [PATCH v2 15/16] KVM: arm64: Restrict EL2 stage-1 changes in protected mode Quentin Perret
2021-07-26  9:29   ` Quentin Perret
2021-07-26  9:29   ` Quentin Perret
2021-07-26 11:27   ` Marc Zyngier
2021-07-26 11:27     ` Marc Zyngier
2021-07-26 11:27     ` Marc Zyngier
2021-07-26 12:55     ` Quentin Perret
2021-07-26 12:55       ` Quentin Perret
2021-07-26 12:55       ` Quentin Perret
2021-07-26  9:29 ` [PATCH v2 16/16] KVM: arm64: Make __pkvm_create_mappings static Quentin Perret
2021-07-26  9:29   ` Quentin Perret
2021-07-26  9:29   ` Quentin Perret

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=YP604j6B1pkhAnT1@google.com \
    --to=qperret@google.com \
    --cc=alexandru.elisei@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=dbrazdil@google.com \
    --cc=james.morse@arm.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=qwandor@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.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 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.