All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Quentin Perret <qperret@google.com>
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 11:35:10 +0100	[thread overview]
Message-ID: <87pmv5e529.wl-maz@kernel.org> (raw)
In-Reply-To: <20210726092905.2198501-5-qperret@google.com>

On Mon, 26 Jul 2021 10:28:53 +0100,
Quentin Perret <qperret@google.com> wrote:
> 
> The kvm_pgtable_stage2_find_range() function is used in the host memory
> abort path to try and look for the largest block mapping that can be
> used to map the faulting address. In order to do so, the function
> currently walks the stage-2 page-table and looks for existing
> incompatible mappings within the range of the largest possible block.
> If incompatible mappings are found, it tries the same procedure again,
> but using a smaller block range, and repeats until a matching range is
> found (potentially up to page granularity). While this approach has
> benefits (mostly in the fact that it proactively coalesces host stage-2
> mappings), it can be slow if the ranges are fragmented, and it isn't
> optimized to deal with CPUs faulting on the same IPA as all of them will
> do all the work every time.
> 
> To avoid these issues, remove kvm_pgtable_stage2_find_range(), and walk
> the page-table only once in the host_mem_abort() path to find the
> closest leaf to the input address. With this, use the corresponding
> range if it is invalid and not owned by another entity. If a valid leaf
> is found, return -EAGAIN similar to what is done in the
> kvm_pgtable_stage2_map() path to optimize concurrent faults.
> 
> Signed-off-by: Quentin Perret <qperret@google.com>
> ---
>  arch/arm64/include/asm/kvm_pgtable.h  | 30 -----------
>  arch/arm64/kvm/hyp/nvhe/mem_protect.c | 39 +++++++++++++-
>  arch/arm64/kvm/hyp/pgtable.c          | 74 ---------------------------
>  3 files changed, 38 insertions(+), 105 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> index 5a7a13bbd4a1..cec76a49f521 100644
> --- a/arch/arm64/include/asm/kvm_pgtable.h
> +++ b/arch/arm64/include/asm/kvm_pgtable.h
> @@ -141,16 +141,6 @@ enum kvm_pgtable_prot {
>  #define PAGE_HYP_RO		(KVM_PGTABLE_PROT_R)
>  #define PAGE_HYP_DEVICE		(PAGE_HYP | KVM_PGTABLE_PROT_DEVICE)
>  
> -/**
> - * struct kvm_mem_range - Range of Intermediate Physical Addresses
> - * @start:	Start of the range.
> - * @end:	End of the range.
> - */
> -struct kvm_mem_range {
> -	u64 start;
> -	u64 end;
> -};
> -
>  /**
>   * enum kvm_pgtable_walk_flags - Flags to control a depth-first page-table walk.
>   * @KVM_PGTABLE_WALK_LEAF:		Visit leaf entries, including invalid
> @@ -477,24 +467,4 @@ int kvm_pgtable_walk(struct kvm_pgtable *pgt, u64 addr, u64 size,
>   */
>  int kvm_pgtable_get_leaf(struct kvm_pgtable *pgt, u64 addr,
>  			 kvm_pte_t *ptep, u32 *level);
> -
> -/**
> - * kvm_pgtable_stage2_find_range() - Find a range of Intermediate Physical
> - *				     Addresses with compatible permission
> - *				     attributes.
> - * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
> - * @addr:	Address that must be covered by the range.
> - * @prot:	Protection attributes that the range must be compatible with.
> - * @range:	Range structure used to limit the search space at call time and
> - *		that will hold the result.
> - *
> - * The offset of @addr within a page is ignored. An IPA is compatible with @prot
> - * iff its corresponding stage-2 page-table entry has default ownership and, if
> - * valid, is mapped with protection attributes identical to @prot.
> - *
> - * Return: 0 on success, negative error code on failure.
> - */
> -int kvm_pgtable_stage2_find_range(struct kvm_pgtable *pgt, u64 addr,
> -				  enum kvm_pgtable_prot prot,
> -				  struct kvm_mem_range *range);
>  #endif	/* __ARM64_KVM_PGTABLE_H__ */
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 871149246f5f..01700a908bb7 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -159,6 +159,11 @@ static int host_stage2_unmap_dev_all(void)
>  	return kvm_pgtable_stage2_unmap(pgt, addr, BIT(pgt->ia_bits) - addr);
>  }
>  
> +struct kvm_mem_range {
> +	u64 start;
> +	u64 end;
> +};
> +
>  static bool find_mem_range(phys_addr_t addr, struct kvm_mem_range *range)
>  {
>  	int cur, left = 0, right = hyp_memblock_nr;
> @@ -227,6 +232,38 @@ static inline int __host_stage2_idmap(u64 start, u64 end,
>  		__ret;							\
>  	 })
>
> +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'?

> +{
> +	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.

> +	range->start = start;
> +	range->end = end;
> +
> +	return 0;
> +}
> +
>  static int host_stage2_idmap(u64 addr)
>  {
>  	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W;
> @@ -238,7 +275,7 @@ static int host_stage2_idmap(u64 addr)
>  		prot |= KVM_PGTABLE_PROT_X;
>  
>  	hyp_spin_lock(&host_kvm.lock);
> -	ret = kvm_pgtable_stage2_find_range(&host_kvm.pgt, addr, prot, &range);
> +	ret = host_stage2_find_range(addr, &range);
>  	if (ret)
>  		goto unlock;

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.
_______________________________________________
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: Marc Zyngier <maz@kernel.org>
To: Quentin Perret <qperret@google.com>
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 11:35:10 +0100	[thread overview]
Message-ID: <87pmv5e529.wl-maz@kernel.org> (raw)
In-Reply-To: <20210726092905.2198501-5-qperret@google.com>

On Mon, 26 Jul 2021 10:28:53 +0100,
Quentin Perret <qperret@google.com> wrote:
> 
> The kvm_pgtable_stage2_find_range() function is used in the host memory
> abort path to try and look for the largest block mapping that can be
> used to map the faulting address. In order to do so, the function
> currently walks the stage-2 page-table and looks for existing
> incompatible mappings within the range of the largest possible block.
> If incompatible mappings are found, it tries the same procedure again,
> but using a smaller block range, and repeats until a matching range is
> found (potentially up to page granularity). While this approach has
> benefits (mostly in the fact that it proactively coalesces host stage-2
> mappings), it can be slow if the ranges are fragmented, and it isn't
> optimized to deal with CPUs faulting on the same IPA as all of them will
> do all the work every time.
> 
> To avoid these issues, remove kvm_pgtable_stage2_find_range(), and walk
> the page-table only once in the host_mem_abort() path to find the
> closest leaf to the input address. With this, use the corresponding
> range if it is invalid and not owned by another entity. If a valid leaf
> is found, return -EAGAIN similar to what is done in the
> kvm_pgtable_stage2_map() path to optimize concurrent faults.
> 
> Signed-off-by: Quentin Perret <qperret@google.com>
> ---
>  arch/arm64/include/asm/kvm_pgtable.h  | 30 -----------
>  arch/arm64/kvm/hyp/nvhe/mem_protect.c | 39 +++++++++++++-
>  arch/arm64/kvm/hyp/pgtable.c          | 74 ---------------------------
>  3 files changed, 38 insertions(+), 105 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> index 5a7a13bbd4a1..cec76a49f521 100644
> --- a/arch/arm64/include/asm/kvm_pgtable.h
> +++ b/arch/arm64/include/asm/kvm_pgtable.h
> @@ -141,16 +141,6 @@ enum kvm_pgtable_prot {
>  #define PAGE_HYP_RO		(KVM_PGTABLE_PROT_R)
>  #define PAGE_HYP_DEVICE		(PAGE_HYP | KVM_PGTABLE_PROT_DEVICE)
>  
> -/**
> - * struct kvm_mem_range - Range of Intermediate Physical Addresses
> - * @start:	Start of the range.
> - * @end:	End of the range.
> - */
> -struct kvm_mem_range {
> -	u64 start;
> -	u64 end;
> -};
> -
>  /**
>   * enum kvm_pgtable_walk_flags - Flags to control a depth-first page-table walk.
>   * @KVM_PGTABLE_WALK_LEAF:		Visit leaf entries, including invalid
> @@ -477,24 +467,4 @@ int kvm_pgtable_walk(struct kvm_pgtable *pgt, u64 addr, u64 size,
>   */
>  int kvm_pgtable_get_leaf(struct kvm_pgtable *pgt, u64 addr,
>  			 kvm_pte_t *ptep, u32 *level);
> -
> -/**
> - * kvm_pgtable_stage2_find_range() - Find a range of Intermediate Physical
> - *				     Addresses with compatible permission
> - *				     attributes.
> - * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
> - * @addr:	Address that must be covered by the range.
> - * @prot:	Protection attributes that the range must be compatible with.
> - * @range:	Range structure used to limit the search space at call time and
> - *		that will hold the result.
> - *
> - * The offset of @addr within a page is ignored. An IPA is compatible with @prot
> - * iff its corresponding stage-2 page-table entry has default ownership and, if
> - * valid, is mapped with protection attributes identical to @prot.
> - *
> - * Return: 0 on success, negative error code on failure.
> - */
> -int kvm_pgtable_stage2_find_range(struct kvm_pgtable *pgt, u64 addr,
> -				  enum kvm_pgtable_prot prot,
> -				  struct kvm_mem_range *range);
>  #endif	/* __ARM64_KVM_PGTABLE_H__ */
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 871149246f5f..01700a908bb7 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -159,6 +159,11 @@ static int host_stage2_unmap_dev_all(void)
>  	return kvm_pgtable_stage2_unmap(pgt, addr, BIT(pgt->ia_bits) - addr);
>  }
>  
> +struct kvm_mem_range {
> +	u64 start;
> +	u64 end;
> +};
> +
>  static bool find_mem_range(phys_addr_t addr, struct kvm_mem_range *range)
>  {
>  	int cur, left = 0, right = hyp_memblock_nr;
> @@ -227,6 +232,38 @@ static inline int __host_stage2_idmap(u64 start, u64 end,
>  		__ret;							\
>  	 })
>
> +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'?

> +{
> +	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.

> +	range->start = start;
> +	range->end = end;
> +
> +	return 0;
> +}
> +
>  static int host_stage2_idmap(u64 addr)
>  {
>  	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W;
> @@ -238,7 +275,7 @@ static int host_stage2_idmap(u64 addr)
>  		prot |= KVM_PGTABLE_PROT_X;
>  
>  	hyp_spin_lock(&host_kvm.lock);
> -	ret = kvm_pgtable_stage2_find_range(&host_kvm.pgt, addr, prot, &range);
> +	ret = host_stage2_find_range(addr, &range);
>  	if (ret)
>  		goto unlock;

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
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: Quentin Perret <qperret@google.com>
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 11:35:10 +0100	[thread overview]
Message-ID: <87pmv5e529.wl-maz@kernel.org> (raw)
In-Reply-To: <20210726092905.2198501-5-qperret@google.com>

On Mon, 26 Jul 2021 10:28:53 +0100,
Quentin Perret <qperret@google.com> wrote:
> 
> The kvm_pgtable_stage2_find_range() function is used in the host memory
> abort path to try and look for the largest block mapping that can be
> used to map the faulting address. In order to do so, the function
> currently walks the stage-2 page-table and looks for existing
> incompatible mappings within the range of the largest possible block.
> If incompatible mappings are found, it tries the same procedure again,
> but using a smaller block range, and repeats until a matching range is
> found (potentially up to page granularity). While this approach has
> benefits (mostly in the fact that it proactively coalesces host stage-2
> mappings), it can be slow if the ranges are fragmented, and it isn't
> optimized to deal with CPUs faulting on the same IPA as all of them will
> do all the work every time.
> 
> To avoid these issues, remove kvm_pgtable_stage2_find_range(), and walk
> the page-table only once in the host_mem_abort() path to find the
> closest leaf to the input address. With this, use the corresponding
> range if it is invalid and not owned by another entity. If a valid leaf
> is found, return -EAGAIN similar to what is done in the
> kvm_pgtable_stage2_map() path to optimize concurrent faults.
> 
> Signed-off-by: Quentin Perret <qperret@google.com>
> ---
>  arch/arm64/include/asm/kvm_pgtable.h  | 30 -----------
>  arch/arm64/kvm/hyp/nvhe/mem_protect.c | 39 +++++++++++++-
>  arch/arm64/kvm/hyp/pgtable.c          | 74 ---------------------------
>  3 files changed, 38 insertions(+), 105 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> index 5a7a13bbd4a1..cec76a49f521 100644
> --- a/arch/arm64/include/asm/kvm_pgtable.h
> +++ b/arch/arm64/include/asm/kvm_pgtable.h
> @@ -141,16 +141,6 @@ enum kvm_pgtable_prot {
>  #define PAGE_HYP_RO		(KVM_PGTABLE_PROT_R)
>  #define PAGE_HYP_DEVICE		(PAGE_HYP | KVM_PGTABLE_PROT_DEVICE)
>  
> -/**
> - * struct kvm_mem_range - Range of Intermediate Physical Addresses
> - * @start:	Start of the range.
> - * @end:	End of the range.
> - */
> -struct kvm_mem_range {
> -	u64 start;
> -	u64 end;
> -};
> -
>  /**
>   * enum kvm_pgtable_walk_flags - Flags to control a depth-first page-table walk.
>   * @KVM_PGTABLE_WALK_LEAF:		Visit leaf entries, including invalid
> @@ -477,24 +467,4 @@ int kvm_pgtable_walk(struct kvm_pgtable *pgt, u64 addr, u64 size,
>   */
>  int kvm_pgtable_get_leaf(struct kvm_pgtable *pgt, u64 addr,
>  			 kvm_pte_t *ptep, u32 *level);
> -
> -/**
> - * kvm_pgtable_stage2_find_range() - Find a range of Intermediate Physical
> - *				     Addresses with compatible permission
> - *				     attributes.
> - * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
> - * @addr:	Address that must be covered by the range.
> - * @prot:	Protection attributes that the range must be compatible with.
> - * @range:	Range structure used to limit the search space at call time and
> - *		that will hold the result.
> - *
> - * The offset of @addr within a page is ignored. An IPA is compatible with @prot
> - * iff its corresponding stage-2 page-table entry has default ownership and, if
> - * valid, is mapped with protection attributes identical to @prot.
> - *
> - * Return: 0 on success, negative error code on failure.
> - */
> -int kvm_pgtable_stage2_find_range(struct kvm_pgtable *pgt, u64 addr,
> -				  enum kvm_pgtable_prot prot,
> -				  struct kvm_mem_range *range);
>  #endif	/* __ARM64_KVM_PGTABLE_H__ */
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 871149246f5f..01700a908bb7 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -159,6 +159,11 @@ static int host_stage2_unmap_dev_all(void)
>  	return kvm_pgtable_stage2_unmap(pgt, addr, BIT(pgt->ia_bits) - addr);
>  }
>  
> +struct kvm_mem_range {
> +	u64 start;
> +	u64 end;
> +};
> +
>  static bool find_mem_range(phys_addr_t addr, struct kvm_mem_range *range)
>  {
>  	int cur, left = 0, right = hyp_memblock_nr;
> @@ -227,6 +232,38 @@ static inline int __host_stage2_idmap(u64 start, u64 end,
>  		__ret;							\
>  	 })
>
> +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'?

> +{
> +	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.

> +	range->start = start;
> +	range->end = end;
> +
> +	return 0;
> +}
> +
>  static int host_stage2_idmap(u64 addr)
>  {
>  	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W;
> @@ -238,7 +275,7 @@ static int host_stage2_idmap(u64 addr)
>  		prot |= KVM_PGTABLE_PROT_X;
>  
>  	hyp_spin_lock(&host_kvm.lock);
> -	ret = kvm_pgtable_stage2_find_range(&host_kvm.pgt, addr, prot, &range);
> +	ret = host_stage2_find_range(addr, &range);
>  	if (ret)
>  		goto unlock;

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2021-07-26 10:35 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 [this message]
2021-07-26 10:35     ` Marc Zyngier
2021-07-26 10:35     ` Marc Zyngier
2021-07-26 13:13     ` Quentin Perret
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=87pmv5e529.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@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=qperret@google.com \
    --cc=qwandor@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.