mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Oliver Upton <oupton@kernel.org>, Marc Zyngier <maz@kernel.org>
Cc: KVM <kvm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>
Subject: linux-next: manual merge of the kvm-arm tree with the kvm tree
Date: Mon, 19 Oct 2026 17:46:15 +0100	[thread overview]
Message-ID: <atZJV1B79VsZoy8u@sirena.co.uk> (raw)

[-- Attachment #1: Type: text/plain, Size: 5752 bytes --]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kvm/mmu.c

between commit:

  dd0bc00e3e920 ("Merge branch kvm-arm64/cca-7.4 into kvmarm-master/next")

from the kvm tree and commits:

  b44a8c32f0116 ("KVM: arm64: Abstract out memory abort handling")
  892c8a0bcc8e3 ("Merge branch kvm-arm64/cca-7.4 into kvmarm-master/next")

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --combined arch/arm64/kvm/mmu.c
index 6e28ded84b4d2,c9622b6e4c741..0000000000000
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@@ -329,6 -329,9 +329,9 @@@ static void kvm_vm_stage2_unmap_range(s
  	struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
  	int (*fn)(struct kvm_pgtable *, u64, u64);
  
+ 	lockdep_assert_held_write(&kvm->mmu_lock);
+ 	WARN_ON(size & ~PAGE_MASK);
+ 
  	if (kvm_is_nested_s2_mmu(kvm, mmu))
  		fn = kvm_pgtable_stage2_unmap_tracked;
  	else
@@@ -1585,11 -1588,32 +1588,11 @@@ transparent_hugepage_adjust(const struc
  	return PAGE_SIZE;
  }
  
 -static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
 +static int get_vma_page_shift(struct vm_area_struct *vma)
  {
 -	unsigned long pa;
 -
 -	if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
 +	if (vma_is_hugetlb(vma))
  		return huge_page_shift(hstate_vma(vma));
  
 -	if (!(vma->vm_flags & VM_PFNMAP))
 -		return PAGE_SHIFT;
 -
 -	VM_BUG_ON(is_vm_hugetlb_page(vma));
 -
 -	pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
 -
 -#ifndef __PAGETABLE_PMD_FOLDED
 -	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
 -	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
 -	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
 -		return PUD_SHIFT;
 -#endif
 -
 -	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
 -	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
 -	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
 -		return PMD_SHIFT;
 -
  	return PAGE_SHIFT;
  }
  
@@@ -1927,7 -1951,7 +1930,7 @@@ static short kvm_s2_resolve_vma_size(co
  		vma_shift = PAGE_SHIFT;
  	} else {
  		s2vi->max_map_size = PUD_SIZE;
 -		vma_shift = get_vma_page_shift(vma, s2fd->hva);
 +		vma_shift = get_vma_page_shift(vma);
  	}
  
  	switch (vma_shift) {
@@@ -2078,6 -2102,16 +2081,6 @@@ static int kvm_s2_fault_pin_pfn(const s
  				return -EFAULT;
  			}
  		} else {
 -			/*
 -			 * If the page was identified as device early by looking at
 -			 * the VMA flags, vma_pagesize is already representing the
 -			 * largest quantity we can map.  If instead it was mapped
 -			 * via __kvm_faultin_pfn(), vma_pagesize is set to PAGE_SIZE
 -			 * and must not be upgraded.
 -			 *
 -			 * In both cases, we don't let transparent_hugepage_adjust()
 -			 * change things at the last minute.
 -			 */
  			s2vi->map_non_cacheable = true;
  		}
  
@@@ -2179,10 -2213,10 +2182,10 @@@ static int kvm_s2_fault_map(const struc
  
  	/*
  	 * If we are not forced to use page mapping, check if we are
 -	 * backed by a THP and thus use block mapping if possible.
 +	 * backed by a huge stage-1 mapping and thus use block mapping if
 +	 * possible.
  	 */
 -	if (mapping_size == PAGE_SIZE &&
 -	    !(s2vi->max_map_size == PAGE_SIZE || s2vi->map_non_cacheable)) {
 +	if (mapping_size == PAGE_SIZE && s2vi->max_map_size != PAGE_SIZE) {
  		if (perm_fault_granule > PAGE_SIZE) {
  			mapping_size = perm_fault_granule;
  		} else {
@@@ -2276,6 -2310,10 +2279,6 @@@ static int user_mem_abort(const struct 
  			return ret;
  	}
  
 -	/*
 -	 * Let's check if we will get back a huge page backed by hugetlbfs, or
 -	 * get block mapping for device MMIO region.
 -	 */
  	ret = kvm_s2_fault_pin_pfn(s2fd, &s2vi);
  	if (ret == -EHWPOISON) {
  		/* If result is specified, let the caller handle this. */
@@@ -2298,9 -2336,11 +2301,11 @@@
  
  static int kvm_vm_mem_abort(const struct kvm_s2_fault_desc *s2fd)
  {
- 	VM_WARN_ON_ONCE(kvm_s2_fault_is_perm(s2fd) &&
- 			!esr_abt_is_write_fault(s2fd->esr) &&
- 			!kvm_s2_fault_is_exec(s2fd));
+ 	struct kvm_vcpu *vcpu = s2fd->vcpu;
+ 
+ 	VM_WARN_ON_ONCE(kvm_vcpu_trap_is_permission_fault(vcpu) &&
+ 			!kvm_is_write_fault(vcpu) &&
+ 			!esr_abt_is_exec_fault(kvm_vcpu_get_esr(vcpu)));
  
  	if (kvm_slot_has_gmem(s2fd->memslot))
  		return gmem_abort(s2fd, NULL);
@@@ -2953,18 -2993,18 +2958,18 @@@ void kvm_set_way_flush(struct kvm_vcpu 
  
  	/*
  	 * If this is the first time we do a S/W operation
 -	 * (i.e. HCR_TVM not set) flush the whole memory, and set the
 +	 * (i.e. HCR_EL2_TVM not set) flush the whole memory, and set the
  	 * VM trapping.
  	 *
  	 * Otherwise, rely on the VM trapping to wait for the MMU +
  	 * Caches to be turned off. At that point, we'll be able to
  	 * clean the caches again.
  	 */
 -	if (!(hcr & HCR_TVM)) {
 +	if (!(hcr & HCR_EL2_TVM)) {
  		trace_kvm_set_way_flush(*vcpu_pc(vcpu),
  					vcpu_has_cache_enabled(vcpu));
  		stage2_flush_vm(vcpu->kvm);
 -		*vcpu_hcr(vcpu) = hcr | HCR_TVM;
 +		*vcpu_hcr(vcpu) = hcr | HCR_EL2_TVM;
  	}
  }
  
@@@ -2982,7 -3022,7 +2987,7 @@@ void kvm_toggle_cache(struct kvm_vcpu *
  
  	/* Caches are now on, stop trapping VM ops (until a S/W op) */
  	if (now_enabled)
 -		*vcpu_hcr(vcpu) &= ~HCR_TVM;
 +		*vcpu_hcr(vcpu) &= ~HCR_EL2_TVM;
  
  	trace_kvm_toggle_cache(*vcpu_pc(vcpu), was_enabled, now_enabled);
  }

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

             reply	other threads:[~2026-10-19 16:46 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 16:46 Mark Brown [this message]
2026-10-19 16:56 ` Paolo Bonzini
  -- strict thread matches above, loose matches on Subject: below --
2023-04-06  3:06 Stephen Rothwell
2023-03-31  2:26 Stephen Rothwell
2022-12-01  2:16 Stephen Rothwell
2022-12-01 15:23 ` Marc Zyngier
2022-12-01  1:09 Stephen Rothwell
2022-12-01  0:57 Stephen Rothwell
2022-12-01  0:36 Stephen Rothwell
2022-12-01  0:24 Stephen Rothwell
2022-07-18  5:19 Stephen Rothwell
2022-05-05  4:47 Stephen Rothwell
2021-12-17  4:19 Stephen Rothwell
2021-12-09 22:01 broonie
2021-06-25  5:24 Stephen Rothwell
2021-06-25  5:20 Stephen Rothwell
2021-06-25  5:15 Stephen Rothwell
2021-06-23  5:53 Stephen Rothwell
2021-06-22  5:31 Stephen Rothwell
2021-04-22  4:43 Stephen Rothwell
2021-04-22  4:39 Stephen Rothwell
2020-07-13  4:40 Stephen Rothwell
2020-08-09  8:55 ` Stephen Rothwell
2020-07-13  4:39 Stephen Rothwell
2020-08-09  8:54 ` Stephen Rothwell
2020-03-25  3:23 Stephen Rothwell
2018-10-18  2:46 Stephen Rothwell
2017-04-10  3:52 Stephen Rothwell
2017-04-10  6:26 ` Christoffer Dall
2016-07-24  6:04 Stephen Rothwell
2016-07-24  5:59 Stephen Rothwell
2016-07-20  5:27 Stephen Rothwell
2015-10-16  3:53 Stephen Rothwell
2015-10-16  4:20 ` Wu, Feng
2014-11-26  6:19 Stephen Rothwell
2014-11-26 11:39 ` Christoffer Dall
2014-09-25  5:32 Stephen Rothwell
2014-09-18  3:52 Stephen Rothwell
2014-09-18 15:13 ` Marc Zyngier
2014-09-08  6:04 Stephen Rothwell

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=atZJV1B79VsZoy8u@sirena.co.uk \
    --to=broonie@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=suzuki.poulose@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®