All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Perret <qperret@google.com>
To: Will Deacon <will@kernel.org>
Cc: catalin.marinas@arm.com, maz@kernel.org, james.morse@arm.com,
	julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com,
	android-kvm@google.com, linux-kernel@vger.kernel.org,
	kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org, tabba@google.com,
	mark.rutland@arm.com, dbrazdil@google.com, mate.toth-pal@arm.com,
	seanjc@google.com, robh+dt@kernel.org, ardb@kernel.org
Subject: Re: [PATCH v4 28/34] KVM: arm64: Use page-table to track page ownership
Date: Fri, 12 Mar 2021 11:45:26 +0000	[thread overview]
Message-ID: <YEtUVriUSi/MFGit@google.com> (raw)
In-Reply-To: <20210312111804.GB32208@willie-the-truck>

On Friday 12 Mar 2021 at 11:18:05 (+0000), Will Deacon wrote:
> On Fri, Mar 12, 2021 at 10:13:26AM +0000, Quentin Perret wrote:
> > On Friday 12 Mar 2021 at 09:32:06 (+0000), Will Deacon wrote:
> > > I'm not saying to use the VMID directly, just that allocating half of the
> > > pte feels a bit OTT given that the state of things after this patch series
> > > is that we're using exactly 1 bit.
> > 
> > Right, and that was the reason for the PROT_NONE approach in the
> > previous version, but we agreed it'd be worth generalizing to allow for
> > future use-cases :-)
> 
> Yeah, just generalising to 32 bits feels like going too far! I dunno,
> make it a u8 for now, or define the hypervisor owner ID as 1 and reject
> owners greater than that? We can easily extend it later.

Alrighty I'll do _both_

> > > > > > @@ -517,28 +543,36 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
> > > > > >  	if (!kvm_block_mapping_supported(addr, end, phys, level))
> > > > > >  		return -E2BIG;
> > > > > >  
> > > > > > -	new = kvm_init_valid_leaf_pte(phys, data->attr, level);
> > > > > > -	if (kvm_pte_valid(old)) {
> > > > > > +	if (kvm_pte_valid(data->attr))
> > > > > 
> > > > > This feels like a bit of a hack to me: the 'attr' field in stage2_map_data
> > > > > is intended to correspond directly to the lower/upper attributes of the
> > > > > descriptor as per the architecture, so tagging the valid bit in there is
> > > > > pretty grotty. However, I can see the significant advantage in being able
> > > > > to re-use the stage2_map_walker functionality, so about instead of nobbling
> > > > > attr, you set phys to something invalid instead, e.g.:
> > > > > 
> > > > > 	#define KVM_PHYS_SET_OWNER	(-1ULL)
> > > > 
> > > > That'll confuse kvm_block_mapping_supported() and friends I think, at
> > > > least in their current form. If you _really_ don't like this, maybe we
> > > > could have an extra 'flags' field in stage2_map_data?
> > > 
> > > I was pondering this last night and I thought of two ways to do it:
> > > 
> > > 1. Add a 'bool valid' and then stick the owner and the phys in a union.
> > >    (yes, you'll need to update the block mapping checks to look at the
> > >     valid flag)
> > 
> > Right, though that is also used for the hyp s1 which doesn't use any of
> > this ATM. That shouldn't be too bad to change, I'll have a look.
> 
> Oh, I meant stick the bool in the stage2_map_data so that should be limited
> to the stage2 path.

I mean I still want to use kvm_block_mapping_supported() but ignore the
phys check when it's not valid. I find it ugly to add a 'valid'
parameter to the function itself, so maybe we're better off with just
special casing phys == -1ULL as you first suggested. How much do you hate
the below (totally untested)?

diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 8e4599256969..9ec937462fd6 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -71,6 +71,13 @@ static u64 kvm_granule_size(u32 level)
        return BIT(kvm_granule_shift(level));
 }

+#define KVM_PHYS_INVALID (-1ULL)
+
+static bool kvm_phys_is_valid(u64 phys)
+{
+       return phys != KVM_PHYS_INVALID;
+}
+
 static bool kvm_level_support_block_mappings(u32 level)
 {
        /*
@@ -90,7 +97,10 @@ static bool kvm_block_mapping_supported(u64 addr, u64 end, u64 phys, u32 level)
        if (granule > (end - addr))
                return false;

-       return IS_ALIGNED(addr, granule) && IS_ALIGNED(phys, granule);
+       if (kvm_phys_is_valid(phys) && !IS_ALIGNED(phys, granule))
+               return false;
+
+       return IS_ALIGNED(addr, granule);
 }

 static u32 kvm_pgtable_idx(struct kvm_pgtable_walk_data *data, u32 level)
@@ -550,7 +560,7 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
        if (!kvm_block_mapping_supported(addr, end, phys, level))
                return -E2BIG;

-       if (kvm_pte_valid(data->attr))
+       if (kvm_phys_is_valid(phys))
                new = kvm_init_valid_leaf_pte(phys, data->attr, level);
        else
                new = kvm_init_invalid_leaf_owner(data->owner_id);
@@ -580,7 +590,8 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
        smp_store_release(ptep, new);
        if (stage2_pte_is_counted(new))
                mm_ops->get_page(ptep);
-       data->phys += granule;
+       if (kvm_phys_is_valid(phys))
+               data->phys += granule;
        return 0;
 }

@@ -739,9 +750,6 @@ int kvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
        if (ret)
                return ret;

-       /* Set the valid flag to distinguish with the set_owner() path. */
-       map_data.attr |= KVM_PTE_VALID;
-
        ret = kvm_pgtable_walk(pgt, addr, size, &walker);
        dsb(ishst);
        return ret;
@@ -752,6 +760,7 @@ int kvm_pgtable_stage2_set_owner(struct kvm_pgtable *pgt, u64 addr, u64 size,
 {
        int ret;
        struct stage2_map_data map_data = {
+               .phys           = KVM_PHYS_INVALID,
                .mmu            = pgt->mmu,
                .memcache       = mc,
                .mm_ops         = pgt->mm_ops,




WARNING: multiple messages have this Message-ID (diff)
From: Quentin Perret <qperret@google.com>
To: Will Deacon <will@kernel.org>
Cc: android-kvm@google.com, catalin.marinas@arm.com,
	mate.toth-pal@arm.com, seanjc@google.com, tabba@google.com,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	linux-arm-kernel@lists.infradead.org, maz@kernel.org,
	kernel-team@android.com, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v4 28/34] KVM: arm64: Use page-table to track page ownership
Date: Fri, 12 Mar 2021 11:45:26 +0000	[thread overview]
Message-ID: <YEtUVriUSi/MFGit@google.com> (raw)
In-Reply-To: <20210312111804.GB32208@willie-the-truck>

On Friday 12 Mar 2021 at 11:18:05 (+0000), Will Deacon wrote:
> On Fri, Mar 12, 2021 at 10:13:26AM +0000, Quentin Perret wrote:
> > On Friday 12 Mar 2021 at 09:32:06 (+0000), Will Deacon wrote:
> > > I'm not saying to use the VMID directly, just that allocating half of the
> > > pte feels a bit OTT given that the state of things after this patch series
> > > is that we're using exactly 1 bit.
> > 
> > Right, and that was the reason for the PROT_NONE approach in the
> > previous version, but we agreed it'd be worth generalizing to allow for
> > future use-cases :-)
> 
> Yeah, just generalising to 32 bits feels like going too far! I dunno,
> make it a u8 for now, or define the hypervisor owner ID as 1 and reject
> owners greater than that? We can easily extend it later.

Alrighty I'll do _both_

> > > > > > @@ -517,28 +543,36 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
> > > > > >  	if (!kvm_block_mapping_supported(addr, end, phys, level))
> > > > > >  		return -E2BIG;
> > > > > >  
> > > > > > -	new = kvm_init_valid_leaf_pte(phys, data->attr, level);
> > > > > > -	if (kvm_pte_valid(old)) {
> > > > > > +	if (kvm_pte_valid(data->attr))
> > > > > 
> > > > > This feels like a bit of a hack to me: the 'attr' field in stage2_map_data
> > > > > is intended to correspond directly to the lower/upper attributes of the
> > > > > descriptor as per the architecture, so tagging the valid bit in there is
> > > > > pretty grotty. However, I can see the significant advantage in being able
> > > > > to re-use the stage2_map_walker functionality, so about instead of nobbling
> > > > > attr, you set phys to something invalid instead, e.g.:
> > > > > 
> > > > > 	#define KVM_PHYS_SET_OWNER	(-1ULL)
> > > > 
> > > > That'll confuse kvm_block_mapping_supported() and friends I think, at
> > > > least in their current form. If you _really_ don't like this, maybe we
> > > > could have an extra 'flags' field in stage2_map_data?
> > > 
> > > I was pondering this last night and I thought of two ways to do it:
> > > 
> > > 1. Add a 'bool valid' and then stick the owner and the phys in a union.
> > >    (yes, you'll need to update the block mapping checks to look at the
> > >     valid flag)
> > 
> > Right, though that is also used for the hyp s1 which doesn't use any of
> > this ATM. That shouldn't be too bad to change, I'll have a look.
> 
> Oh, I meant stick the bool in the stage2_map_data so that should be limited
> to the stage2 path.

I mean I still want to use kvm_block_mapping_supported() but ignore the
phys check when it's not valid. I find it ugly to add a 'valid'
parameter to the function itself, so maybe we're better off with just
special casing phys == -1ULL as you first suggested. How much do you hate
the below (totally untested)?

diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 8e4599256969..9ec937462fd6 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -71,6 +71,13 @@ static u64 kvm_granule_size(u32 level)
        return BIT(kvm_granule_shift(level));
 }

+#define KVM_PHYS_INVALID (-1ULL)
+
+static bool kvm_phys_is_valid(u64 phys)
+{
+       return phys != KVM_PHYS_INVALID;
+}
+
 static bool kvm_level_support_block_mappings(u32 level)
 {
        /*
@@ -90,7 +97,10 @@ static bool kvm_block_mapping_supported(u64 addr, u64 end, u64 phys, u32 level)
        if (granule > (end - addr))
                return false;

-       return IS_ALIGNED(addr, granule) && IS_ALIGNED(phys, granule);
+       if (kvm_phys_is_valid(phys) && !IS_ALIGNED(phys, granule))
+               return false;
+
+       return IS_ALIGNED(addr, granule);
 }

 static u32 kvm_pgtable_idx(struct kvm_pgtable_walk_data *data, u32 level)
@@ -550,7 +560,7 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
        if (!kvm_block_mapping_supported(addr, end, phys, level))
                return -E2BIG;

-       if (kvm_pte_valid(data->attr))
+       if (kvm_phys_is_valid(phys))
                new = kvm_init_valid_leaf_pte(phys, data->attr, level);
        else
                new = kvm_init_invalid_leaf_owner(data->owner_id);
@@ -580,7 +590,8 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
        smp_store_release(ptep, new);
        if (stage2_pte_is_counted(new))
                mm_ops->get_page(ptep);
-       data->phys += granule;
+       if (kvm_phys_is_valid(phys))
+               data->phys += granule;
        return 0;
 }

@@ -739,9 +750,6 @@ int kvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
        if (ret)
                return ret;

-       /* Set the valid flag to distinguish with the set_owner() path. */
-       map_data.attr |= KVM_PTE_VALID;
-
        ret = kvm_pgtable_walk(pgt, addr, size, &walker);
        dsb(ishst);
        return ret;
@@ -752,6 +760,7 @@ int kvm_pgtable_stage2_set_owner(struct kvm_pgtable *pgt, u64 addr, u64 size,
 {
        int ret;
        struct stage2_map_data map_data = {
+               .phys           = KVM_PHYS_INVALID,
                .mmu            = pgt->mmu,
                .memcache       = mc,
                .mm_ops         = pgt->mm_ops,



_______________________________________________
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: Will Deacon <will@kernel.org>
Cc: catalin.marinas@arm.com, maz@kernel.org, james.morse@arm.com,
	julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com,
	android-kvm@google.com, linux-kernel@vger.kernel.org,
	kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org, tabba@google.com,
	mark.rutland@arm.com, dbrazdil@google.com, mate.toth-pal@arm.com,
	seanjc@google.com, robh+dt@kernel.org, ardb@kernel.org
Subject: Re: [PATCH v4 28/34] KVM: arm64: Use page-table to track page ownership
Date: Fri, 12 Mar 2021 11:45:26 +0000	[thread overview]
Message-ID: <YEtUVriUSi/MFGit@google.com> (raw)
In-Reply-To: <20210312111804.GB32208@willie-the-truck>

On Friday 12 Mar 2021 at 11:18:05 (+0000), Will Deacon wrote:
> On Fri, Mar 12, 2021 at 10:13:26AM +0000, Quentin Perret wrote:
> > On Friday 12 Mar 2021 at 09:32:06 (+0000), Will Deacon wrote:
> > > I'm not saying to use the VMID directly, just that allocating half of the
> > > pte feels a bit OTT given that the state of things after this patch series
> > > is that we're using exactly 1 bit.
> > 
> > Right, and that was the reason for the PROT_NONE approach in the
> > previous version, but we agreed it'd be worth generalizing to allow for
> > future use-cases :-)
> 
> Yeah, just generalising to 32 bits feels like going too far! I dunno,
> make it a u8 for now, or define the hypervisor owner ID as 1 and reject
> owners greater than that? We can easily extend it later.

Alrighty I'll do _both_

> > > > > > @@ -517,28 +543,36 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
> > > > > >  	if (!kvm_block_mapping_supported(addr, end, phys, level))
> > > > > >  		return -E2BIG;
> > > > > >  
> > > > > > -	new = kvm_init_valid_leaf_pte(phys, data->attr, level);
> > > > > > -	if (kvm_pte_valid(old)) {
> > > > > > +	if (kvm_pte_valid(data->attr))
> > > > > 
> > > > > This feels like a bit of a hack to me: the 'attr' field in stage2_map_data
> > > > > is intended to correspond directly to the lower/upper attributes of the
> > > > > descriptor as per the architecture, so tagging the valid bit in there is
> > > > > pretty grotty. However, I can see the significant advantage in being able
> > > > > to re-use the stage2_map_walker functionality, so about instead of nobbling
> > > > > attr, you set phys to something invalid instead, e.g.:
> > > > > 
> > > > > 	#define KVM_PHYS_SET_OWNER	(-1ULL)
> > > > 
> > > > That'll confuse kvm_block_mapping_supported() and friends I think, at
> > > > least in their current form. If you _really_ don't like this, maybe we
> > > > could have an extra 'flags' field in stage2_map_data?
> > > 
> > > I was pondering this last night and I thought of two ways to do it:
> > > 
> > > 1. Add a 'bool valid' and then stick the owner and the phys in a union.
> > >    (yes, you'll need to update the block mapping checks to look at the
> > >     valid flag)
> > 
> > Right, though that is also used for the hyp s1 which doesn't use any of
> > this ATM. That shouldn't be too bad to change, I'll have a look.
> 
> Oh, I meant stick the bool in the stage2_map_data so that should be limited
> to the stage2 path.

I mean I still want to use kvm_block_mapping_supported() but ignore the
phys check when it's not valid. I find it ugly to add a 'valid'
parameter to the function itself, so maybe we're better off with just
special casing phys == -1ULL as you first suggested. How much do you hate
the below (totally untested)?

diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 8e4599256969..9ec937462fd6 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -71,6 +71,13 @@ static u64 kvm_granule_size(u32 level)
        return BIT(kvm_granule_shift(level));
 }

+#define KVM_PHYS_INVALID (-1ULL)
+
+static bool kvm_phys_is_valid(u64 phys)
+{
+       return phys != KVM_PHYS_INVALID;
+}
+
 static bool kvm_level_support_block_mappings(u32 level)
 {
        /*
@@ -90,7 +97,10 @@ static bool kvm_block_mapping_supported(u64 addr, u64 end, u64 phys, u32 level)
        if (granule > (end - addr))
                return false;

-       return IS_ALIGNED(addr, granule) && IS_ALIGNED(phys, granule);
+       if (kvm_phys_is_valid(phys) && !IS_ALIGNED(phys, granule))
+               return false;
+
+       return IS_ALIGNED(addr, granule);
 }

 static u32 kvm_pgtable_idx(struct kvm_pgtable_walk_data *data, u32 level)
@@ -550,7 +560,7 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
        if (!kvm_block_mapping_supported(addr, end, phys, level))
                return -E2BIG;

-       if (kvm_pte_valid(data->attr))
+       if (kvm_phys_is_valid(phys))
                new = kvm_init_valid_leaf_pte(phys, data->attr, level);
        else
                new = kvm_init_invalid_leaf_owner(data->owner_id);
@@ -580,7 +590,8 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
        smp_store_release(ptep, new);
        if (stage2_pte_is_counted(new))
                mm_ops->get_page(ptep);
-       data->phys += granule;
+       if (kvm_phys_is_valid(phys))
+               data->phys += granule;
        return 0;
 }

@@ -739,9 +750,6 @@ int kvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
        if (ret)
                return ret;

-       /* Set the valid flag to distinguish with the set_owner() path. */
-       map_data.attr |= KVM_PTE_VALID;
-
        ret = kvm_pgtable_walk(pgt, addr, size, &walker);
        dsb(ishst);
        return ret;
@@ -752,6 +760,7 @@ int kvm_pgtable_stage2_set_owner(struct kvm_pgtable *pgt, u64 addr, u64 size,
 {
        int ret;
        struct stage2_map_data map_data = {
+               .phys           = KVM_PHYS_INVALID,
                .mmu            = pgt->mmu,
                .memcache       = mc,
                .mm_ops         = pgt->mm_ops,




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

  reply	other threads:[~2021-03-12 11:46 UTC|newest]

Thread overview: 177+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 17:57 [PATCH v4 00/34] KVM: arm64: A stage 2 for the host Quentin Perret
2021-03-10 17:57 ` Quentin Perret
2021-03-10 17:57 ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 01/34] arm64: lib: Annotate {clear,copy}_page() as position-independent Quentin Perret
2021-03-10 17:57   ` [PATCH v4 01/34] arm64: lib: Annotate {clear, copy}_page() " Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 02/34] KVM: arm64: Link position-independent string routines into .hyp.text Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 03/34] arm64: kvm: Add standalone ticket spinlock implementation for use at hyp Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 04/34] KVM: arm64: Initialize kvm_nvhe_init_params early Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 05/34] KVM: arm64: Avoid free_page() in page-table allocator Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 06/34] KVM: arm64: Factor memory allocation out of pgtable.c Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 16:09   ` Will Deacon
2021-03-11 16:09     ` Will Deacon
2021-03-11 16:09     ` Will Deacon
2021-03-10 17:57 ` [PATCH v4 07/34] KVM: arm64: Introduce a BSS section for use at Hyp Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 08/34] KVM: arm64: Make kvm_call_hyp() a function call " Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 09/34] KVM: arm64: Allow using kvm_nvhe_sym() in hyp code Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 10/34] KVM: arm64: Introduce an early Hyp page allocator Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 11/34] KVM: arm64: Stub CONFIG_DEBUG_LIST at Hyp Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 16:11   ` Will Deacon
2021-03-11 16:11     ` Will Deacon
2021-03-11 16:11     ` Will Deacon
2021-03-10 17:57 ` [PATCH v4 12/34] KVM: arm64: Introduce a Hyp buddy page allocator Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 16:14   ` Will Deacon
2021-03-11 16:14     ` Will Deacon
2021-03-11 16:14     ` Will Deacon
2021-03-10 17:57 ` [PATCH v4 13/34] KVM: arm64: Enable access to sanitized CPU features at EL2 Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 19:36   ` Will Deacon
2021-03-11 19:36     ` Will Deacon
2021-03-11 19:36     ` Will Deacon
2021-03-12  6:34     ` Quentin Perret
2021-03-12  6:34       ` Quentin Perret
2021-03-12  6:34       ` Quentin Perret
2021-03-12  9:25       ` Will Deacon
2021-03-12  9:25         ` Will Deacon
2021-03-12  9:25         ` Will Deacon
2021-03-10 17:57 ` [PATCH v4 14/34] KVM: arm64: Factor out vector address calculation Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 15/34] arm64: asm: Provide set_sctlr_el2 macro Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 16:22   ` Will Deacon
2021-03-11 16:22     ` Will Deacon
2021-03-11 16:22     ` Will Deacon
2021-03-10 17:57 ` [PATCH v4 16/34] KVM: arm64: Prepare the creation of s1 mappings at EL2 Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 16:21   ` Will Deacon
2021-03-11 16:21     ` Will Deacon
2021-03-11 16:21     ` Will Deacon
2021-03-10 17:57 ` [PATCH v4 17/34] KVM: arm64: Elevate hypervisor mappings creation " Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 17:28   ` Will Deacon
2021-03-11 17:28     ` Will Deacon
2021-03-11 17:28     ` Will Deacon
2021-03-10 17:57 ` [PATCH v4 18/34] KVM: arm64: Use kvm_arch for stage 2 pgtable Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 19/34] KVM: arm64: Use kvm_arch in kvm_s2_mmu Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 20/34] KVM: arm64: Set host stage 2 using kvm_nvhe_init_params Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 21/34] KVM: arm64: Refactor kvm_arm_setup_stage2() Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 22/34] KVM: arm64: Refactor __load_guest_stage2() Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 23/34] KVM: arm64: Refactor __populate_fault_info() Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 24/34] KVM: arm64: Make memcache anonymous in pgtable allocator Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 25/34] KVM: arm64: Reserve memory for host stage 2 Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 26/34] KVM: arm64: Sort the hypervisor memblocks Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 27/34] KVM: arm64: Always zero invalid PTEs Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 17:33   ` Will Deacon
2021-03-11 17:33     ` Will Deacon
2021-03-11 17:33     ` Will Deacon
2021-03-12  9:15     ` Quentin Perret
2021-03-12  9:15       ` Quentin Perret
2021-03-12  9:15       ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 28/34] KVM: arm64: Use page-table to track page ownership Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 18:38   ` Will Deacon
2021-03-11 18:38     ` Will Deacon
2021-03-11 18:38     ` Will Deacon
2021-03-12  6:23     ` Quentin Perret
2021-03-12  6:23       ` Quentin Perret
2021-03-12  6:23       ` Quentin Perret
2021-03-12  9:32       ` Will Deacon
2021-03-12  9:32         ` Will Deacon
2021-03-12  9:32         ` Will Deacon
2021-03-12 10:13         ` Quentin Perret
2021-03-12 10:13           ` Quentin Perret
2021-03-12 10:13           ` Quentin Perret
2021-03-12 11:18           ` Will Deacon
2021-03-12 11:18             ` Will Deacon
2021-03-12 11:18             ` Will Deacon
2021-03-12 11:45             ` Quentin Perret [this message]
2021-03-12 11:45               ` Quentin Perret
2021-03-12 11:45               ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 29/34] KVM: arm64: Refactor stage2_map_set_prot_attr() Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 18:48   ` Will Deacon
2021-03-11 18:48     ` Will Deacon
2021-03-11 18:48     ` Will Deacon
2021-03-12  5:10     ` Quentin Perret
2021-03-12  5:10       ` Quentin Perret
2021-03-12  5:10       ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 30/34] KVM: arm64: Add kvm_pgtable_stage2_find_range() Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 19:04   ` Will Deacon
2021-03-11 19:04     ` Will Deacon
2021-03-11 19:04     ` Will Deacon
2021-03-12  5:32     ` Quentin Perret
2021-03-12  5:32       ` Quentin Perret
2021-03-12  5:32       ` Quentin Perret
2021-03-12  9:40       ` Will Deacon
2021-03-12  9:40         ` Will Deacon
2021-03-12  9:40         ` Will Deacon
2021-03-10 17:57 ` [PATCH v4 31/34] KVM: arm64: Wrap the host with a stage 2 Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 19:09   ` Will Deacon
2021-03-11 19:09     ` Will Deacon
2021-03-11 19:09     ` Will Deacon
2021-03-10 17:57 ` [PATCH v4 32/34] KVM: arm64: Page-align the .hyp sections Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 33/34] KVM: arm64: Disable PMU support in protected mode Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57 ` [PATCH v4 34/34] KVM: arm64: Protect the .hyp sections from the host Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-10 17:57   ` Quentin Perret
2021-03-11 19:17   ` Will Deacon
2021-03-11 19:17     ` Will Deacon
2021-03-11 19:17     ` 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=YEtUVriUSi/MFGit@google.com \
    --to=qperret@google.com \
    --cc=android-kvm@google.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=dbrazdil@google.com \
    --cc=james.morse@arm.com \
    --cc=julien.thierry.kdev@gmail.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=mark.rutland@arm.com \
    --cc=mate.toth-pal@arm.com \
    --cc=maz@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=seanjc@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.