All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
	kvmarm@lists.cs.columbia.edu
Cc: marc.zyngier@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org,
	Christoffer Dall <christoffer.dall@arm.com>,
	punitagrawal@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v9 1/8] KVM: arm/arm64: Share common code in user_mem_abort()
Date: Mon, 3 Dec 2018 13:37:37 +0000	[thread overview]
Message-ID: <8fd34e5f-7d75-4de2-3fee-d6d70805685c@arm.com> (raw)
In-Reply-To: <ad4b316a-054f-24d9-d32d-8fbe7972b5ad@arm.com>

Hi Anshuman,

On 03/12/2018 12:11, Anshuman Khandual wrote:
> 
> 
> On 10/31/2018 11:27 PM, Punit Agrawal wrote:
>> The code for operations such as marking the pfn as dirty, and
>> dcache/icache maintenance during stage 2 fault handling is duplicated
>> between normal pages and PMD hugepages.
>>
>> Instead of creating another copy of the operations when we introduce
>> PUD hugepages, let's share them across the different pagesizes.
>>
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Cc: Christoffer Dall <christoffer.dall@arm.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>>   virt/kvm/arm/mmu.c | 49 ++++++++++++++++++++++++++++------------------
>>   1 file changed, 30 insertions(+), 19 deletions(-)
>>
>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>> index 5eca48bdb1a6..59595207c5e1 100644
>> --- a/virt/kvm/arm/mmu.c
>> +++ b/virt/kvm/arm/mmu.c
>> @@ -1475,7 +1475,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   			  unsigned long fault_status)
>>   {
>>   	int ret;
>> -	bool write_fault, exec_fault, writable, hugetlb = false, force_pte = false;
>> +	bool write_fault, exec_fault, writable, force_pte = false;
>>   	unsigned long mmu_seq;
>>   	gfn_t gfn = fault_ipa >> PAGE_SHIFT;
>>   	struct kvm *kvm = vcpu->kvm;
>> @@ -1484,7 +1484,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   	kvm_pfn_t pfn;
>>   	pgprot_t mem_type = PAGE_S2;
>>   	bool logging_active = memslot_is_logging(memslot);
>> -	unsigned long flags = 0;
>> +	unsigned long vma_pagesize, flags = 0;
> 
> A small nit s/vma_pagesize/pagesize. Why call it VMA ? Its implicit.

May be we could call it mapsize. pagesize is confusing.

> 
>>   
>>   	write_fault = kvm_is_write_fault(vcpu);
>>   	exec_fault = kvm_vcpu_trap_is_iabt(vcpu);
>> @@ -1504,10 +1504,16 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   		return -EFAULT;
>>   	}
>>   
>> -	if (vma_kernel_pagesize(vma) == PMD_SIZE && !logging_active) {
>> -		hugetlb = true;
>> +	vma_pagesize = vma_kernel_pagesize(vma);
>> +	if (vma_pagesize == PMD_SIZE && !logging_active) {
>>   		gfn = (fault_ipa & PMD_MASK) >> PAGE_SHIFT;
>>   	} else {
>> +		/*
>> +		 * Fallback to PTE if it's not one of the Stage 2
>> +		 * supported hugepage sizes
>> +		 */
>> +		vma_pagesize = PAGE_SIZE;
> 
> This seems redundant and should be dropped. vma_kernel_pagesize() here either
> calls hugetlb_vm_op_pagesize (via hugetlb_vm_ops->pagesize) or simply returns
> PAGE_SIZE. The vm_ops path is taken if the QEMU VMA covering any given HVA is
> backed either by HugeTLB pages or simply normal pages. vma_pagesize would
> either has a value of PMD_SIZE (HugeTLB hstate based) or PAGE_SIZE. Hence if
> its not PMD_SIZE it must be PAGE_SIZE which should not be assigned again.

We may want to force using the PTE mappings when logging_active (e.g, migration
?) to prevent keep tracking of huge pages. So the check is still valid.


> 
>> +
>>   		/*
>>   		 * Pages belonging to memslots that don't have the same
>>   		 * alignment for userspace and IPA cannot be mapped using
>> @@ -1573,23 +1579,33 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   	if (mmu_notifier_retry(kvm, mmu_seq))
>>   		goto out_unlock;
>>   
>> -	if (!hugetlb && !force_pte)
>> -		hugetlb = transparent_hugepage_adjust(&pfn, &fault_ipa);
>> +	if (vma_pagesize == PAGE_SIZE && !force_pte) {
>> +		/*
>> +		 * Only PMD_SIZE transparent hugepages(THP) are
>> +		 * currently supported. This code will need to be
>> +		 * updated to support other THP sizes.
>> +		 */
> 
> This comment belongs to transparent_hugepage_adjust() but not here.

I think this is relevant here than in thp_adjust, unless we rename
the function below to something generic, handle_hugepage_adjust().

>> +		if (transparent_hugepage_adjust(&pfn, &fault_ipa))
>> +			vma_pagesize = PMD_SIZE;
> 
> IIUC transparent_hugepage_adjust() is only getting called here. Instead of
> returning 'true' when it is able to detect a huge page backing and doing
> an adjustment there after, it should rather return THP size (PMD_SIZE) to
> accommodate probable multi size THP support in future .

That makes sense.

> 
>> +	}
>> +
>> +	if (writable)
>> +		kvm_set_pfn_dirty(pfn);
>>   
>> -	if (hugetlb) {
>> +	if (fault_status != FSC_PERM)
>> +		clean_dcache_guest_page(pfn, vma_pagesize);
>> +
>> +	if (exec_fault)
>> +		invalidate_icache_guest_page(pfn, vma_pagesize);
>> +
>> +	if (vma_pagesize == PMD_SIZE) {
>>   		pmd_t new_pmd = pfn_pmd(pfn, mem_type);
>>   		new_pmd = pmd_mkhuge(new_pmd);
>> -		if (writable) {
>> +		if (writable)
>>   			new_pmd = kvm_s2pmd_mkwrite(new_pmd);
>> -			kvm_set_pfn_dirty(pfn);
>> -		}
>> -
>> -		if (fault_status != FSC_PERM)
>> -			clean_dcache_guest_page(pfn, PMD_SIZE);
>>   
>>   		if (exec_fault) {
>>   			new_pmd = kvm_s2pmd_mkexec(new_pmd);
>> -			invalidate_icache_guest_page(pfn, PMD_SIZE);
>>   		} else if (fault_status == FSC_PERM) {
>>   			/* Preserve execute if XN was already cleared */
>>   			if (stage2_is_exec(kvm, fault_ipa))
>> @@ -1602,16 +1618,11 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   
>>   		if (writable) {
>>   			new_pte = kvm_s2pte_mkwrite(new_pte);
>> -			kvm_set_pfn_dirty(pfn);
>>   			mark_page_dirty(kvm, gfn);
>>   		}
>>   
>> -		if (fault_status != FSC_PERM)
>> -			clean_dcache_guest_page(pfn, PAGE_SIZE);
>> -
>>   		if (exec_fault) {
>>   			new_pte = kvm_s2pte_mkexec(new_pte);
>> -			invalidate_icache_guest_page(pfn, PAGE_SIZE);
>>   		} else if (fault_status == FSC_PERM) {
>>   			/* Preserve execute if XN was already cleared */
>>   			if (stage2_is_exec(kvm, fault_ipa))
>>
> 
> kvm_set_pfn_dirty, clean_dcache_guest_page, invalidate_icache_guest_page
> can all be safely moved before setting the page table entries either as
> PMD or PTE.

I think this is what we do currently. So I assume this is fine.

Cheers
Suzuki

WARNING: multiple messages have this Message-ID (diff)
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
	kvmarm@lists.cs.columbia.edu
Cc: marc.zyngier@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v9 1/8] KVM: arm/arm64: Share common code in user_mem_abort()
Date: Mon, 3 Dec 2018 13:37:37 +0000	[thread overview]
Message-ID: <8fd34e5f-7d75-4de2-3fee-d6d70805685c@arm.com> (raw)
In-Reply-To: <ad4b316a-054f-24d9-d32d-8fbe7972b5ad@arm.com>

Hi Anshuman,

On 03/12/2018 12:11, Anshuman Khandual wrote:
> 
> 
> On 10/31/2018 11:27 PM, Punit Agrawal wrote:
>> The code for operations such as marking the pfn as dirty, and
>> dcache/icache maintenance during stage 2 fault handling is duplicated
>> between normal pages and PMD hugepages.
>>
>> Instead of creating another copy of the operations when we introduce
>> PUD hugepages, let's share them across the different pagesizes.
>>
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Cc: Christoffer Dall <christoffer.dall@arm.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>>   virt/kvm/arm/mmu.c | 49 ++++++++++++++++++++++++++++------------------
>>   1 file changed, 30 insertions(+), 19 deletions(-)
>>
>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>> index 5eca48bdb1a6..59595207c5e1 100644
>> --- a/virt/kvm/arm/mmu.c
>> +++ b/virt/kvm/arm/mmu.c
>> @@ -1475,7 +1475,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   			  unsigned long fault_status)
>>   {
>>   	int ret;
>> -	bool write_fault, exec_fault, writable, hugetlb = false, force_pte = false;
>> +	bool write_fault, exec_fault, writable, force_pte = false;
>>   	unsigned long mmu_seq;
>>   	gfn_t gfn = fault_ipa >> PAGE_SHIFT;
>>   	struct kvm *kvm = vcpu->kvm;
>> @@ -1484,7 +1484,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   	kvm_pfn_t pfn;
>>   	pgprot_t mem_type = PAGE_S2;
>>   	bool logging_active = memslot_is_logging(memslot);
>> -	unsigned long flags = 0;
>> +	unsigned long vma_pagesize, flags = 0;
> 
> A small nit s/vma_pagesize/pagesize. Why call it VMA ? Its implicit.

May be we could call it mapsize. pagesize is confusing.

> 
>>   
>>   	write_fault = kvm_is_write_fault(vcpu);
>>   	exec_fault = kvm_vcpu_trap_is_iabt(vcpu);
>> @@ -1504,10 +1504,16 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   		return -EFAULT;
>>   	}
>>   
>> -	if (vma_kernel_pagesize(vma) == PMD_SIZE && !logging_active) {
>> -		hugetlb = true;
>> +	vma_pagesize = vma_kernel_pagesize(vma);
>> +	if (vma_pagesize == PMD_SIZE && !logging_active) {
>>   		gfn = (fault_ipa & PMD_MASK) >> PAGE_SHIFT;
>>   	} else {
>> +		/*
>> +		 * Fallback to PTE if it's not one of the Stage 2
>> +		 * supported hugepage sizes
>> +		 */
>> +		vma_pagesize = PAGE_SIZE;
> 
> This seems redundant and should be dropped. vma_kernel_pagesize() here either
> calls hugetlb_vm_op_pagesize (via hugetlb_vm_ops->pagesize) or simply returns
> PAGE_SIZE. The vm_ops path is taken if the QEMU VMA covering any given HVA is
> backed either by HugeTLB pages or simply normal pages. vma_pagesize would
> either has a value of PMD_SIZE (HugeTLB hstate based) or PAGE_SIZE. Hence if
> its not PMD_SIZE it must be PAGE_SIZE which should not be assigned again.

We may want to force using the PTE mappings when logging_active (e.g, migration
?) to prevent keep tracking of huge pages. So the check is still valid.


> 
>> +
>>   		/*
>>   		 * Pages belonging to memslots that don't have the same
>>   		 * alignment for userspace and IPA cannot be mapped using
>> @@ -1573,23 +1579,33 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   	if (mmu_notifier_retry(kvm, mmu_seq))
>>   		goto out_unlock;
>>   
>> -	if (!hugetlb && !force_pte)
>> -		hugetlb = transparent_hugepage_adjust(&pfn, &fault_ipa);
>> +	if (vma_pagesize == PAGE_SIZE && !force_pte) {
>> +		/*
>> +		 * Only PMD_SIZE transparent hugepages(THP) are
>> +		 * currently supported. This code will need to be
>> +		 * updated to support other THP sizes.
>> +		 */
> 
> This comment belongs to transparent_hugepage_adjust() but not here.

I think this is relevant here than in thp_adjust, unless we rename
the function below to something generic, handle_hugepage_adjust().

>> +		if (transparent_hugepage_adjust(&pfn, &fault_ipa))
>> +			vma_pagesize = PMD_SIZE;
> 
> IIUC transparent_hugepage_adjust() is only getting called here. Instead of
> returning 'true' when it is able to detect a huge page backing and doing
> an adjustment there after, it should rather return THP size (PMD_SIZE) to
> accommodate probable multi size THP support in future .

That makes sense.

> 
>> +	}
>> +
>> +	if (writable)
>> +		kvm_set_pfn_dirty(pfn);
>>   
>> -	if (hugetlb) {
>> +	if (fault_status != FSC_PERM)
>> +		clean_dcache_guest_page(pfn, vma_pagesize);
>> +
>> +	if (exec_fault)
>> +		invalidate_icache_guest_page(pfn, vma_pagesize);
>> +
>> +	if (vma_pagesize == PMD_SIZE) {
>>   		pmd_t new_pmd = pfn_pmd(pfn, mem_type);
>>   		new_pmd = pmd_mkhuge(new_pmd);
>> -		if (writable) {
>> +		if (writable)
>>   			new_pmd = kvm_s2pmd_mkwrite(new_pmd);
>> -			kvm_set_pfn_dirty(pfn);
>> -		}
>> -
>> -		if (fault_status != FSC_PERM)
>> -			clean_dcache_guest_page(pfn, PMD_SIZE);
>>   
>>   		if (exec_fault) {
>>   			new_pmd = kvm_s2pmd_mkexec(new_pmd);
>> -			invalidate_icache_guest_page(pfn, PMD_SIZE);
>>   		} else if (fault_status == FSC_PERM) {
>>   			/* Preserve execute if XN was already cleared */
>>   			if (stage2_is_exec(kvm, fault_ipa))
>> @@ -1602,16 +1618,11 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   
>>   		if (writable) {
>>   			new_pte = kvm_s2pte_mkwrite(new_pte);
>> -			kvm_set_pfn_dirty(pfn);
>>   			mark_page_dirty(kvm, gfn);
>>   		}
>>   
>> -		if (fault_status != FSC_PERM)
>> -			clean_dcache_guest_page(pfn, PAGE_SIZE);
>> -
>>   		if (exec_fault) {
>>   			new_pte = kvm_s2pte_mkexec(new_pte);
>> -			invalidate_icache_guest_page(pfn, PAGE_SIZE);
>>   		} else if (fault_status == FSC_PERM) {
>>   			/* Preserve execute if XN was already cleared */
>>   			if (stage2_is_exec(kvm, fault_ipa))
>>
> 
> kvm_set_pfn_dirty, clean_dcache_guest_page, invalidate_icache_guest_page
> can all be safely moved before setting the page table entries either as
> PMD or PTE.

I think this is what we do currently. So I assume this is fine.

Cheers
Suzuki

WARNING: multiple messages have this Message-ID (diff)
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
	kvmarm@lists.cs.columbia.edu
Cc: marc.zyngier@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org,
	Christoffer Dall <christoffer.dall@arm.com>,
	punitagrawal@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v9 1/8] KVM: arm/arm64: Share common code in user_mem_abort()
Date: Mon, 3 Dec 2018 13:37:37 +0000	[thread overview]
Message-ID: <8fd34e5f-7d75-4de2-3fee-d6d70805685c@arm.com> (raw)
In-Reply-To: <ad4b316a-054f-24d9-d32d-8fbe7972b5ad@arm.com>

Hi Anshuman,

On 03/12/2018 12:11, Anshuman Khandual wrote:
> 
> 
> On 10/31/2018 11:27 PM, Punit Agrawal wrote:
>> The code for operations such as marking the pfn as dirty, and
>> dcache/icache maintenance during stage 2 fault handling is duplicated
>> between normal pages and PMD hugepages.
>>
>> Instead of creating another copy of the operations when we introduce
>> PUD hugepages, let's share them across the different pagesizes.
>>
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Cc: Christoffer Dall <christoffer.dall@arm.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>>   virt/kvm/arm/mmu.c | 49 ++++++++++++++++++++++++++++------------------
>>   1 file changed, 30 insertions(+), 19 deletions(-)
>>
>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>> index 5eca48bdb1a6..59595207c5e1 100644
>> --- a/virt/kvm/arm/mmu.c
>> +++ b/virt/kvm/arm/mmu.c
>> @@ -1475,7 +1475,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   			  unsigned long fault_status)
>>   {
>>   	int ret;
>> -	bool write_fault, exec_fault, writable, hugetlb = false, force_pte = false;
>> +	bool write_fault, exec_fault, writable, force_pte = false;
>>   	unsigned long mmu_seq;
>>   	gfn_t gfn = fault_ipa >> PAGE_SHIFT;
>>   	struct kvm *kvm = vcpu->kvm;
>> @@ -1484,7 +1484,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   	kvm_pfn_t pfn;
>>   	pgprot_t mem_type = PAGE_S2;
>>   	bool logging_active = memslot_is_logging(memslot);
>> -	unsigned long flags = 0;
>> +	unsigned long vma_pagesize, flags = 0;
> 
> A small nit s/vma_pagesize/pagesize. Why call it VMA ? Its implicit.

May be we could call it mapsize. pagesize is confusing.

> 
>>   
>>   	write_fault = kvm_is_write_fault(vcpu);
>>   	exec_fault = kvm_vcpu_trap_is_iabt(vcpu);
>> @@ -1504,10 +1504,16 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   		return -EFAULT;
>>   	}
>>   
>> -	if (vma_kernel_pagesize(vma) == PMD_SIZE && !logging_active) {
>> -		hugetlb = true;
>> +	vma_pagesize = vma_kernel_pagesize(vma);
>> +	if (vma_pagesize == PMD_SIZE && !logging_active) {
>>   		gfn = (fault_ipa & PMD_MASK) >> PAGE_SHIFT;
>>   	} else {
>> +		/*
>> +		 * Fallback to PTE if it's not one of the Stage 2
>> +		 * supported hugepage sizes
>> +		 */
>> +		vma_pagesize = PAGE_SIZE;
> 
> This seems redundant and should be dropped. vma_kernel_pagesize() here either
> calls hugetlb_vm_op_pagesize (via hugetlb_vm_ops->pagesize) or simply returns
> PAGE_SIZE. The vm_ops path is taken if the QEMU VMA covering any given HVA is
> backed either by HugeTLB pages or simply normal pages. vma_pagesize would
> either has a value of PMD_SIZE (HugeTLB hstate based) or PAGE_SIZE. Hence if
> its not PMD_SIZE it must be PAGE_SIZE which should not be assigned again.

We may want to force using the PTE mappings when logging_active (e.g, migration
?) to prevent keep tracking of huge pages. So the check is still valid.


> 
>> +
>>   		/*
>>   		 * Pages belonging to memslots that don't have the same
>>   		 * alignment for userspace and IPA cannot be mapped using
>> @@ -1573,23 +1579,33 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   	if (mmu_notifier_retry(kvm, mmu_seq))
>>   		goto out_unlock;
>>   
>> -	if (!hugetlb && !force_pte)
>> -		hugetlb = transparent_hugepage_adjust(&pfn, &fault_ipa);
>> +	if (vma_pagesize == PAGE_SIZE && !force_pte) {
>> +		/*
>> +		 * Only PMD_SIZE transparent hugepages(THP) are
>> +		 * currently supported. This code will need to be
>> +		 * updated to support other THP sizes.
>> +		 */
> 
> This comment belongs to transparent_hugepage_adjust() but not here.

I think this is relevant here than in thp_adjust, unless we rename
the function below to something generic, handle_hugepage_adjust().

>> +		if (transparent_hugepage_adjust(&pfn, &fault_ipa))
>> +			vma_pagesize = PMD_SIZE;
> 
> IIUC transparent_hugepage_adjust() is only getting called here. Instead of
> returning 'true' when it is able to detect a huge page backing and doing
> an adjustment there after, it should rather return THP size (PMD_SIZE) to
> accommodate probable multi size THP support in future .

That makes sense.

> 
>> +	}
>> +
>> +	if (writable)
>> +		kvm_set_pfn_dirty(pfn);
>>   
>> -	if (hugetlb) {
>> +	if (fault_status != FSC_PERM)
>> +		clean_dcache_guest_page(pfn, vma_pagesize);
>> +
>> +	if (exec_fault)
>> +		invalidate_icache_guest_page(pfn, vma_pagesize);
>> +
>> +	if (vma_pagesize == PMD_SIZE) {
>>   		pmd_t new_pmd = pfn_pmd(pfn, mem_type);
>>   		new_pmd = pmd_mkhuge(new_pmd);
>> -		if (writable) {
>> +		if (writable)
>>   			new_pmd = kvm_s2pmd_mkwrite(new_pmd);
>> -			kvm_set_pfn_dirty(pfn);
>> -		}
>> -
>> -		if (fault_status != FSC_PERM)
>> -			clean_dcache_guest_page(pfn, PMD_SIZE);
>>   
>>   		if (exec_fault) {
>>   			new_pmd = kvm_s2pmd_mkexec(new_pmd);
>> -			invalidate_icache_guest_page(pfn, PMD_SIZE);
>>   		} else if (fault_status == FSC_PERM) {
>>   			/* Preserve execute if XN was already cleared */
>>   			if (stage2_is_exec(kvm, fault_ipa))
>> @@ -1602,16 +1618,11 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   
>>   		if (writable) {
>>   			new_pte = kvm_s2pte_mkwrite(new_pte);
>> -			kvm_set_pfn_dirty(pfn);
>>   			mark_page_dirty(kvm, gfn);
>>   		}
>>   
>> -		if (fault_status != FSC_PERM)
>> -			clean_dcache_guest_page(pfn, PAGE_SIZE);
>> -
>>   		if (exec_fault) {
>>   			new_pte = kvm_s2pte_mkexec(new_pte);
>> -			invalidate_icache_guest_page(pfn, PAGE_SIZE);
>>   		} else if (fault_status == FSC_PERM) {
>>   			/* Preserve execute if XN was already cleared */
>>   			if (stage2_is_exec(kvm, fault_ipa))
>>
> 
> kvm_set_pfn_dirty, clean_dcache_guest_page, invalidate_icache_guest_page
> can all be safely moved before setting the page table entries either as
> PMD or PTE.

I think this is what we do currently. So I assume this is fine.

Cheers
Suzuki

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

  reply	other threads:[~2018-12-03 13:37 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-31 17:57 [PATCH v9 0/8] KVM: Support PUD hugepage at stage 2 Punit Agrawal
2018-10-31 17:57 ` Punit Agrawal
2018-10-31 17:57 ` [PATCH v9 1/8] KVM: arm/arm64: Share common code in user_mem_abort() Punit Agrawal
2018-10-31 17:57   ` Punit Agrawal
2018-10-31 17:57   ` Punit Agrawal
2018-12-03 12:11   ` Anshuman Khandual
2018-12-03 12:11     ` Anshuman Khandual
2018-12-03 13:37     ` Suzuki K Poulose [this message]
2018-12-03 13:37       ` Suzuki K Poulose
2018-12-03 13:37       ` Suzuki K Poulose
2018-12-10  8:56       ` Christoffer Dall
2018-12-10  8:56         ` Christoffer Dall
2018-12-10 10:26         ` Suzuki K Poulose
2018-12-10 10:26           ` Suzuki K Poulose
2018-12-10 10:47         ` Suzuki K Poulose
2018-12-10 10:47           ` Suzuki K Poulose
2018-12-10 11:01           ` Christoffer Dall
2018-12-10 11:01             ` Christoffer Dall
2018-10-31 17:57 ` [PATCH v9 2/8] KVM: arm/arm64: Re-factor setting the Stage 2 entry to exec on fault Punit Agrawal
2018-10-31 17:57   ` Punit Agrawal
2018-12-03 13:32   ` Anshuman Khandual
2018-12-03 13:32     ` Anshuman Khandual
2018-12-05 10:47     ` Suzuki K Poulose
2018-12-05 10:47       ` Suzuki K Poulose
2018-12-10  9:00       ` Christoffer Dall
2018-12-10  9:00         ` Christoffer Dall
2018-12-10  8:59     ` Christoffer Dall
2018-12-10  8:59       ` Christoffer Dall
2018-10-31 17:57 ` [PATCH v9 3/8] KVM: arm/arm64: Introduce helpers to manipulate page table entries Punit Agrawal
2018-10-31 17:57   ` Punit Agrawal
2018-10-31 17:57   ` Punit Agrawal
2018-12-03 13:50   ` Anshuman Khandual
2018-12-03 13:50     ` Anshuman Khandual
2018-12-03 14:03     ` Suzuki K Poulose
2018-12-03 14:03       ` Suzuki K Poulose
2018-12-10  9:01     ` Christoffer Dall
2018-12-10  9:01       ` Christoffer Dall
2018-10-31 17:57 ` [PATCH v9 4/8] KVM: arm64: Support dirty page tracking for PUD hugepages Punit Agrawal
2018-10-31 17:57   ` Punit Agrawal
2018-12-03 14:17   ` Anshuman Khandual
2018-12-03 14:17     ` Anshuman Khandual
2018-12-03 14:21     ` Suzuki K Poulose
2018-12-03 14:21       ` Suzuki K Poulose
2018-10-31 17:57 ` [PATCH v9 5/8] KVM: arm64: Support PUD hugepage in stage2_is_exec() Punit Agrawal
2018-10-31 17:57   ` Punit Agrawal
2018-11-01 13:38   ` Christoffer Dall
2018-11-01 13:38     ` Christoffer Dall
2018-12-05 17:57     ` Suzuki K Poulose
2018-12-05 17:57       ` Suzuki K Poulose
2018-12-10  9:06       ` Christoffer Dall
2018-12-10  9:06         ` Christoffer Dall
2018-12-03 14:37   ` Anshuman Khandual
2018-12-03 14:37     ` Anshuman Khandual
2018-10-31 17:57 ` [PATCH v9 6/8] KVM: arm64: Support handling access faults for PUD hugepages Punit Agrawal
2018-10-31 17:57   ` Punit Agrawal
2018-11-01 13:40   ` Christoffer Dall
2018-11-01 13:40     ` Christoffer Dall
2018-11-01 13:40     ` Christoffer Dall
2018-12-03 15:10   ` Anshuman Khandual
2018-12-03 15:10     ` Anshuman Khandual
2018-10-31 17:57 ` [PATCH v9 7/8] KVM: arm64: Update age handlers to support " Punit Agrawal
2018-10-31 17:57   ` Punit Agrawal
2018-12-03 15:19   ` Anshuman Khandual
2018-12-03 15:19     ` Anshuman Khandual
2018-10-31 17:57 ` [PATCH v9 8/8] KVM: arm64: Add support for creating PUD hugepages at stage 2 Punit Agrawal
2018-10-31 17:57   ` Punit Agrawal
2018-10-31 17:57   ` Punit Agrawal
2018-12-03 15:46   ` Anshuman Khandual
2018-12-03 15:46     ` Anshuman Khandual

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=8fd34e5f-7d75-4de2-3fee-d6d70805685c@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=christoffer.dall@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=punitagrawal@gmail.com \
    --cc=will.deacon@arm.com \
    /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.