All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Quentin Perret <qperret@google.com>
Cc: James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Fuad Tabba <tabba@google.com>,
	David Brazdil <dbrazdil@google.com>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	kernel-team@android.com
Subject: Re: [PATCH 04/16] KVM: arm64: Introduce kvm_share_hyp()
Date: Sun, 17 Oct 2021 11:41:21 +0100	[thread overview]
Message-ID: <875ytworvy.wl-maz@kernel.org> (raw)
In-Reply-To: <20211013155831.943476-5-qperret@google.com>

On Wed, 13 Oct 2021 16:58:19 +0100,
Quentin Perret <qperret@google.com> wrote:
> 
> The create_hyp_mappings() function can currently be called at any point
> in time. However, its behaviour in protected mode changes widely
> depending on when it is being called. Prior to KVM init, it is used to
> create the temporary page-table used to bring-up the hypervisor, and
> later on it is transparently turned into a 'share' hypercall when the
> kernel has lost control over the hypervisor stage-1. In order to prepare
> the ground for also unsharing pages with the hypervisor during guest
> teardown, introduce a kvm_share_hyp() function to make it clear in which
> places a share hypercall should be expected, as we will soon need a
> matching unshare hypercall in all those places.
> 
> Signed-off-by: Quentin Perret <qperret@google.com>
> ---
>  arch/arm64/include/asm/kvm_mmu.h |  1 +
>  arch/arm64/kvm/arm.c             |  7 +++----
>  arch/arm64/kvm/fpsimd.c          |  4 ++--
>  arch/arm64/kvm/mmu.c             | 19 +++++++++++++------
>  4 files changed, 19 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 02d378887743..185d0f62b724 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -150,6 +150,7 @@ static __always_inline unsigned long __kern_hyp_va(unsigned long v)
>  #include <asm/kvm_pgtable.h>
>  #include <asm/stage2_pgtable.h>
>  
> +int kvm_share_hyp(void *from, void *to);
>  int create_hyp_mappings(void *from, void *to, enum kvm_pgtable_prot prot);
>  int create_hyp_io_mappings(phys_addr_t phys_addr, size_t size,
>  			   void __iomem **kaddr,
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index c33d8c073820..f2e74635332b 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -146,7 +146,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>  	if (ret)
>  		return ret;
>  
> -	ret = create_hyp_mappings(kvm, kvm + 1, PAGE_HYP);
> +	ret = kvm_share_hyp(kvm, kvm + 1);
>  	if (ret)
>  		goto out_free_stage2_pgd;
>  
> @@ -341,7 +341,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
>  	if (err)
>  		return err;
>  
> -	return create_hyp_mappings(vcpu, vcpu + 1, PAGE_HYP);
> +	return kvm_share_hyp(vcpu, vcpu + 1);
>  }
>  
>  void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
> @@ -623,8 +623,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>  
>  		sve_end = vcpu->arch.sve_state + vcpu_sve_state_size(vcpu);
>  
> -		ret = create_hyp_mappings(vcpu->arch.sve_state, sve_end,
> -					  PAGE_HYP);
> +		ret = kvm_share_hyp(vcpu->arch.sve_state, sve_end);
>  		if (ret)
>  			return ret;
>  	}
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 62c0d78da7be..2fe1128d9f3d 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -35,11 +35,11 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
>  	 * Make sure the host task thread flags and fpsimd state are
>  	 * visible to hyp:
>  	 */
> -	ret = create_hyp_mappings(ti, ti + 1, PAGE_HYP);
> +	ret = kvm_share_hyp(ti, ti + 1);
>  	if (ret)
>  		goto error;
>  
> -	ret = create_hyp_mappings(fpsimd, fpsimd + 1, PAGE_HYP);
> +	ret = kvm_share_hyp(fpsimd, fpsimd + 1);
>  	if (ret)
>  		goto error;
>  
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 1a94a7ca48f2..f80673e863ac 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -296,6 +296,17 @@ static int pkvm_share_hyp(phys_addr_t start, phys_addr_t end)
>  	return 0;
>  }
>  
> +int kvm_share_hyp(void *from, void *to)
> +{
> +	if (is_kernel_in_hyp_mode())
> +		return 0;
> +
> +	if (kvm_host_owns_hyp_mappings())
> +		return create_hyp_mappings(from, to, PAGE_HYP);

Not directly related to this code, but it looks to me that
kvm_host_owns_hyp_mappings() really ought to check for
is_kernel_in_hyp_mode() on its own. VHE really deals with its own
mappings, and create_hyp_mappings() already has a check to do nothing
on VHE.

> +
> +	return pkvm_share_hyp(kvm_kaddr_to_phys(from), kvm_kaddr_to_phys(to));
> +}
> +
>  /**
>   * create_hyp_mappings - duplicate a kernel virtual address range in Hyp mode
>   * @from:	The virtual kernel start address of the range
> @@ -316,12 +327,8 @@ int create_hyp_mappings(void *from, void *to, enum kvm_pgtable_prot prot)
>  	if (is_kernel_in_hyp_mode())
>  		return 0;
>  
> -	if (!kvm_host_owns_hyp_mappings()) {
> -		if (WARN_ON(prot != PAGE_HYP))
> -			return -EPERM;
> -		return pkvm_share_hyp(kvm_kaddr_to_phys(from),
> -				      kvm_kaddr_to_phys(to));
> -	}
> +	if (WARN_ON(!kvm_host_owns_hyp_mappings()))
> +		return -EPERM;

Do we really need this? Can't we just verify that all the code paths
to create_hyp_mappings() check for kvm_host_owns_hyp_mappings()?

At the very least, make this a VM_BUG_ON() so that this is limited to
debug. Yes, I'm quickly developing a WARN_ON()-phobia.

	M.

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

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Quentin Perret <qperret@google.com>
Cc: kernel-team@android.com, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 04/16] KVM: arm64: Introduce kvm_share_hyp()
Date: Sun, 17 Oct 2021 11:41:21 +0100	[thread overview]
Message-ID: <875ytworvy.wl-maz@kernel.org> (raw)
In-Reply-To: <20211013155831.943476-5-qperret@google.com>

On Wed, 13 Oct 2021 16:58:19 +0100,
Quentin Perret <qperret@google.com> wrote:
> 
> The create_hyp_mappings() function can currently be called at any point
> in time. However, its behaviour in protected mode changes widely
> depending on when it is being called. Prior to KVM init, it is used to
> create the temporary page-table used to bring-up the hypervisor, and
> later on it is transparently turned into a 'share' hypercall when the
> kernel has lost control over the hypervisor stage-1. In order to prepare
> the ground for also unsharing pages with the hypervisor during guest
> teardown, introduce a kvm_share_hyp() function to make it clear in which
> places a share hypercall should be expected, as we will soon need a
> matching unshare hypercall in all those places.
> 
> Signed-off-by: Quentin Perret <qperret@google.com>
> ---
>  arch/arm64/include/asm/kvm_mmu.h |  1 +
>  arch/arm64/kvm/arm.c             |  7 +++----
>  arch/arm64/kvm/fpsimd.c          |  4 ++--
>  arch/arm64/kvm/mmu.c             | 19 +++++++++++++------
>  4 files changed, 19 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 02d378887743..185d0f62b724 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -150,6 +150,7 @@ static __always_inline unsigned long __kern_hyp_va(unsigned long v)
>  #include <asm/kvm_pgtable.h>
>  #include <asm/stage2_pgtable.h>
>  
> +int kvm_share_hyp(void *from, void *to);
>  int create_hyp_mappings(void *from, void *to, enum kvm_pgtable_prot prot);
>  int create_hyp_io_mappings(phys_addr_t phys_addr, size_t size,
>  			   void __iomem **kaddr,
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index c33d8c073820..f2e74635332b 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -146,7 +146,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>  	if (ret)
>  		return ret;
>  
> -	ret = create_hyp_mappings(kvm, kvm + 1, PAGE_HYP);
> +	ret = kvm_share_hyp(kvm, kvm + 1);
>  	if (ret)
>  		goto out_free_stage2_pgd;
>  
> @@ -341,7 +341,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
>  	if (err)
>  		return err;
>  
> -	return create_hyp_mappings(vcpu, vcpu + 1, PAGE_HYP);
> +	return kvm_share_hyp(vcpu, vcpu + 1);
>  }
>  
>  void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
> @@ -623,8 +623,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>  
>  		sve_end = vcpu->arch.sve_state + vcpu_sve_state_size(vcpu);
>  
> -		ret = create_hyp_mappings(vcpu->arch.sve_state, sve_end,
> -					  PAGE_HYP);
> +		ret = kvm_share_hyp(vcpu->arch.sve_state, sve_end);
>  		if (ret)
>  			return ret;
>  	}
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 62c0d78da7be..2fe1128d9f3d 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -35,11 +35,11 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
>  	 * Make sure the host task thread flags and fpsimd state are
>  	 * visible to hyp:
>  	 */
> -	ret = create_hyp_mappings(ti, ti + 1, PAGE_HYP);
> +	ret = kvm_share_hyp(ti, ti + 1);
>  	if (ret)
>  		goto error;
>  
> -	ret = create_hyp_mappings(fpsimd, fpsimd + 1, PAGE_HYP);
> +	ret = kvm_share_hyp(fpsimd, fpsimd + 1);
>  	if (ret)
>  		goto error;
>  
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 1a94a7ca48f2..f80673e863ac 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -296,6 +296,17 @@ static int pkvm_share_hyp(phys_addr_t start, phys_addr_t end)
>  	return 0;
>  }
>  
> +int kvm_share_hyp(void *from, void *to)
> +{
> +	if (is_kernel_in_hyp_mode())
> +		return 0;
> +
> +	if (kvm_host_owns_hyp_mappings())
> +		return create_hyp_mappings(from, to, PAGE_HYP);

Not directly related to this code, but it looks to me that
kvm_host_owns_hyp_mappings() really ought to check for
is_kernel_in_hyp_mode() on its own. VHE really deals with its own
mappings, and create_hyp_mappings() already has a check to do nothing
on VHE.

> +
> +	return pkvm_share_hyp(kvm_kaddr_to_phys(from), kvm_kaddr_to_phys(to));
> +}
> +
>  /**
>   * create_hyp_mappings - duplicate a kernel virtual address range in Hyp mode
>   * @from:	The virtual kernel start address of the range
> @@ -316,12 +327,8 @@ int create_hyp_mappings(void *from, void *to, enum kvm_pgtable_prot prot)
>  	if (is_kernel_in_hyp_mode())
>  		return 0;
>  
> -	if (!kvm_host_owns_hyp_mappings()) {
> -		if (WARN_ON(prot != PAGE_HYP))
> -			return -EPERM;
> -		return pkvm_share_hyp(kvm_kaddr_to_phys(from),
> -				      kvm_kaddr_to_phys(to));
> -	}
> +	if (WARN_ON(!kvm_host_owns_hyp_mappings()))
> +		return -EPERM;

Do we really need this? Can't we just verify that all the code paths
to create_hyp_mappings() check for kvm_host_owns_hyp_mappings()?

At the very least, make this a VM_BUG_ON() so that this is limited to
debug. Yes, I'm quickly developing a WARN_ON()-phobia.

	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 <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Fuad Tabba <tabba@google.com>,
	David Brazdil <dbrazdil@google.com>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	kernel-team@android.com
Subject: Re: [PATCH 04/16] KVM: arm64: Introduce kvm_share_hyp()
Date: Sun, 17 Oct 2021 11:41:21 +0100	[thread overview]
Message-ID: <875ytworvy.wl-maz@kernel.org> (raw)
In-Reply-To: <20211013155831.943476-5-qperret@google.com>

On Wed, 13 Oct 2021 16:58:19 +0100,
Quentin Perret <qperret@google.com> wrote:
> 
> The create_hyp_mappings() function can currently be called at any point
> in time. However, its behaviour in protected mode changes widely
> depending on when it is being called. Prior to KVM init, it is used to
> create the temporary page-table used to bring-up the hypervisor, and
> later on it is transparently turned into a 'share' hypercall when the
> kernel has lost control over the hypervisor stage-1. In order to prepare
> the ground for also unsharing pages with the hypervisor during guest
> teardown, introduce a kvm_share_hyp() function to make it clear in which
> places a share hypercall should be expected, as we will soon need a
> matching unshare hypercall in all those places.
> 
> Signed-off-by: Quentin Perret <qperret@google.com>
> ---
>  arch/arm64/include/asm/kvm_mmu.h |  1 +
>  arch/arm64/kvm/arm.c             |  7 +++----
>  arch/arm64/kvm/fpsimd.c          |  4 ++--
>  arch/arm64/kvm/mmu.c             | 19 +++++++++++++------
>  4 files changed, 19 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 02d378887743..185d0f62b724 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -150,6 +150,7 @@ static __always_inline unsigned long __kern_hyp_va(unsigned long v)
>  #include <asm/kvm_pgtable.h>
>  #include <asm/stage2_pgtable.h>
>  
> +int kvm_share_hyp(void *from, void *to);
>  int create_hyp_mappings(void *from, void *to, enum kvm_pgtable_prot prot);
>  int create_hyp_io_mappings(phys_addr_t phys_addr, size_t size,
>  			   void __iomem **kaddr,
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index c33d8c073820..f2e74635332b 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -146,7 +146,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>  	if (ret)
>  		return ret;
>  
> -	ret = create_hyp_mappings(kvm, kvm + 1, PAGE_HYP);
> +	ret = kvm_share_hyp(kvm, kvm + 1);
>  	if (ret)
>  		goto out_free_stage2_pgd;
>  
> @@ -341,7 +341,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
>  	if (err)
>  		return err;
>  
> -	return create_hyp_mappings(vcpu, vcpu + 1, PAGE_HYP);
> +	return kvm_share_hyp(vcpu, vcpu + 1);
>  }
>  
>  void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
> @@ -623,8 +623,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>  
>  		sve_end = vcpu->arch.sve_state + vcpu_sve_state_size(vcpu);
>  
> -		ret = create_hyp_mappings(vcpu->arch.sve_state, sve_end,
> -					  PAGE_HYP);
> +		ret = kvm_share_hyp(vcpu->arch.sve_state, sve_end);
>  		if (ret)
>  			return ret;
>  	}
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 62c0d78da7be..2fe1128d9f3d 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -35,11 +35,11 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
>  	 * Make sure the host task thread flags and fpsimd state are
>  	 * visible to hyp:
>  	 */
> -	ret = create_hyp_mappings(ti, ti + 1, PAGE_HYP);
> +	ret = kvm_share_hyp(ti, ti + 1);
>  	if (ret)
>  		goto error;
>  
> -	ret = create_hyp_mappings(fpsimd, fpsimd + 1, PAGE_HYP);
> +	ret = kvm_share_hyp(fpsimd, fpsimd + 1);
>  	if (ret)
>  		goto error;
>  
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 1a94a7ca48f2..f80673e863ac 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -296,6 +296,17 @@ static int pkvm_share_hyp(phys_addr_t start, phys_addr_t end)
>  	return 0;
>  }
>  
> +int kvm_share_hyp(void *from, void *to)
> +{
> +	if (is_kernel_in_hyp_mode())
> +		return 0;
> +
> +	if (kvm_host_owns_hyp_mappings())
> +		return create_hyp_mappings(from, to, PAGE_HYP);

Not directly related to this code, but it looks to me that
kvm_host_owns_hyp_mappings() really ought to check for
is_kernel_in_hyp_mode() on its own. VHE really deals with its own
mappings, and create_hyp_mappings() already has a check to do nothing
on VHE.

> +
> +	return pkvm_share_hyp(kvm_kaddr_to_phys(from), kvm_kaddr_to_phys(to));
> +}
> +
>  /**
>   * create_hyp_mappings - duplicate a kernel virtual address range in Hyp mode
>   * @from:	The virtual kernel start address of the range
> @@ -316,12 +327,8 @@ int create_hyp_mappings(void *from, void *to, enum kvm_pgtable_prot prot)
>  	if (is_kernel_in_hyp_mode())
>  		return 0;
>  
> -	if (!kvm_host_owns_hyp_mappings()) {
> -		if (WARN_ON(prot != PAGE_HYP))
> -			return -EPERM;
> -		return pkvm_share_hyp(kvm_kaddr_to_phys(from),
> -				      kvm_kaddr_to_phys(to));
> -	}
> +	if (WARN_ON(!kvm_host_owns_hyp_mappings()))
> +		return -EPERM;

Do we really need this? Can't we just verify that all the code paths
to create_hyp_mappings() check for kvm_host_owns_hyp_mappings()?

At the very least, make this a VM_BUG_ON() so that this is limited to
debug. Yes, I'm quickly developing a WARN_ON()-phobia.

	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

  reply	other threads:[~2021-10-17 10:41 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-13 15:58 [PATCH 00/16] KVM: arm64: Implement unshare hypercall for pkvm Quentin Perret
2021-10-13 15:58 ` Quentin Perret
2021-10-13 15:58 ` Quentin Perret
2021-10-13 15:58 ` [PATCH 01/16] KVM: arm64: Introduce do_share() helper for memory sharing between components Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-15 15:11   ` Andrew Walbran
2021-10-15 15:11     ` Andrew Walbran
2021-10-15 15:11     ` Andrew Walbran
2021-10-19 10:37     ` Quentin Perret
2021-10-19 10:37       ` Quentin Perret
2021-10-19 10:37       ` Quentin Perret
2021-10-13 15:58 ` [PATCH 02/16] KVM: arm64: Implement __pkvm_host_share_hyp() using do_share() Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58 ` [PATCH 03/16] KVM: arm64: Avoid remapping the SVE state in the hyp stage-1 Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-16 11:04   ` Marc Zyngier
2021-10-16 11:04     ` Marc Zyngier
2021-10-16 11:04     ` Marc Zyngier
2021-10-18 10:36     ` Quentin Perret
2021-10-18 10:36       ` Quentin Perret
2021-10-18 10:36       ` Quentin Perret
2021-10-13 15:58 ` [PATCH 04/16] KVM: arm64: Introduce kvm_share_hyp() Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-17 10:41   ` Marc Zyngier [this message]
2021-10-17 10:41     ` Marc Zyngier
2021-10-17 10:41     ` Marc Zyngier
2021-10-18 10:51     ` Quentin Perret
2021-10-18 10:51       ` Quentin Perret
2021-10-18 10:51       ` Quentin Perret
2021-10-13 15:58 ` [PATCH 05/16] KVM: arm64: Accept page ranges in pkvm share hypercall Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58 ` [PATCH 06/16] KVM: arm64: Provide {get,put}_page() stubs for early hyp allocator Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58 ` [PATCH 07/16] KVM: arm64: Refcount hyp stage-1 pgtable pages Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58 ` [PATCH 08/16] KVM: arm64: Fixup hyp stage-1 refcount Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58 ` [PATCH 09/16] KVM: arm64: Hook up ->page_count() for hypervisor stage-1 page-table Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58 ` [PATCH 10/16] KVM: arm64: Implement kvm_pgtable_hyp_unmap() at EL2 Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58 ` [PATCH 11/16] KVM: arm64: Back hyp_vmemmap for all of memory Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58 ` [PATCH 12/16] KVM: arm64: Move hyp refcount helpers to header files Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58 ` [PATCH 13/16] KVM: arm64: Move double-sharing logic into hyp-specific function Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58 ` [PATCH 14/16] KVM: arm64: Refcount shared pages at EL2 Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58 ` [PATCH 15/16] KVM: arm64: pkvm: Introduce an unshare hypercall Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58 ` [PATCH 16/16] KVM: arm64: pkvm: Unshare guest structs during teardown Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-13 15:58   ` Quentin Perret
2021-10-16 12:25   ` Marc Zyngier
2021-10-16 12:25     ` Marc Zyngier
2021-10-16 12:25     ` Marc Zyngier
2021-10-18 10:32     ` Quentin Perret
2021-10-18 10:32       ` Quentin Perret
2021-10-18 10:32       ` Quentin Perret
2021-10-18 14:03       ` Quentin Perret
2021-10-18 14:03         ` Quentin Perret
2021-10-18 14:03         ` Quentin Perret
2021-10-18 17:12         ` Marc Zyngier
2021-10-18 17:12           ` Marc Zyngier
2021-10-18 17:12           ` Marc Zyngier
2021-10-19  9:40           ` Quentin Perret
2021-10-19  9:40             ` Quentin Perret
2021-10-19  9:40             ` 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=875ytworvy.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --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=qperret@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.