Hi Will,
On 9/11/20 2:25 PM, Will Deacon wrote:
> Add support for relaxing the permissions of a stage-2 mapping (i.e.
> adding additional permissions) to the generic page-table code.
>
> Cc: Marc Zyngier <maz@xxxxxxxxxx>
> Cc: Quentin Perret <qperret@xxxxxxxxxx>
> Reviewed-by: Gavin Shan <gshan@xxxxxxxxxx>
> Signed-off-by: Will Deacon <will@xxxxxxxxxx>
> ---
> arch/arm64/include/asm/kvm_pgtable.h | 19 +++++++++++++++++++
> arch/arm64/kvm/hyp/pgtable.c | 20 ++++++++++++++++++++
> 2 files changed, 39 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> index 77c027456c61..52ab38db04c7 100644
> --- a/arch/arm64/include/asm/kvm_pgtable.h
> +++ b/arch/arm64/include/asm/kvm_pgtable.h
> @@ -236,6 +236,25 @@ kvm_pte_t kvm_pgtable_stage2_mkyoung(struct kvm_pgtable *pgt, u64 addr);
> */
> kvm_pte_t kvm_pgtable_stage2_mkold(struct kvm_pgtable *pgt, u64 addr);
>
> +/**
> + * kvm_pgtable_stage2_relax_perms() - Relax the permissions enforced by a
> + * page-table entry.
> + * @pgt: Page-table structure initialised by kvm_pgtable_stage2_init().
> + * @addr: Intermediate physical address to identify the page-table entry.
> + * @prot: Additional permissions to grant for the mapping.
> + *
> + * The offset of @addr within a page is ignored.
> + *
> + * If there is a valid, leaf page-table entry used to translate @addr, then
> + * relax the permissions in that entry according to the read, write and
> + * execute permissions specified by @prot. No permissions are removed, and
> + * TLB invalidation is performed after updating the entry.
> + *
> + * Return: 0 on success, negative error code on failure.
> + */
> +int kvm_pgtable_stage2_relax_perms(struct kvm_pgtable *pgt, u64 addr,
> + enum kvm_pgtable_prot prot);
> +
> /**
> * kvm_pgtable_stage2_is_young() - Test whether a page-table entry has the
> * access flag set.
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index d382756a527c..603d6b415337 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -782,6 +782,26 @@ bool kvm_pgtable_stage2_is_young(struct kvm_pgtable *pgt, u64 addr)
> return pte & KVM_PTE_LEAF_ATTR_LO_S2_AF;
> }
>
> +int kvm_pgtable_stage2_relax_perms(struct kvm_pgtable *pgt, u64 addr,
> + enum kvm_pgtable_prot prot)
> +{
> + int ret;
> + kvm_pte_t set = 0, clr = 0;
> +
> + if (prot & KVM_PGTABLE_PROT_R)
> + set |= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R;
> +
> + if (prot & KVM_PGTABLE_PROT_W)
> + set |= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W;
> +
> + if (prot & KVM_PGTABLE_PROT_X)
> + clr |= KVM_PTE_LEAF_ATTR_HI_S2_XN;
> +
> + ret = stage2_update_leaf_attrs(pgt, addr, 1, set, clr, NULL);
> + kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, pgt->mmu, addr, 0);
We know the level at which the entry is updated, as the visitor has a "level"
parameter, I was wondering if it makes sense to do the TLBI invalidation there.
Struct stage2_attr_data could have an extra field to control if the invalidation
should be done in the visitor.
Thanks,
Alex
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
