From: Sean Christopherson <seanjc@google.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Lisa Wang <wyihan@google.com>,
Andrew Jones <ajones@ventanamicro.com>,
Ackerley Tng <ackerleytng@google.com>,
Binbin Wu <binbin.wu@linux.intel.com>,
Chao Gao <chao.gao@intel.com>,
Chenyi Qiang <chenyi.qiang@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Erdem Aktas <erdemaktas@google.com>,
Ira Weiny <ira.weiny@intel.com>,
Isaku Yamahata <isaku.yamahata@intel.com>,
Kiryl Shutsemau <kas@kernel.org>,
linux-kselftest@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>,
"Pratik R. Sampat" <pratikrajesh.sampat@amd.com>,
Reinette Chatre <reinette.chatre@intel.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Roger Wang <runanwang@google.com>,
Ryan Afranji <afranji@google.com>,
Sagi Shahar <sagis@google.com>, Shuah Khan <shuah@kernel.org>,
Oliver Upton <oupton@kernel.org>,
Jeremiah McReynolds <jmcrey@google.com>,
kvm@vger.kernel.org, linux-coco@lists.linux.dev,
linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH v14 13/22] KVM: selftests: Support guest_memfd in-place conversion
Date: Mon, 12 Oct 2026 08:26:16 -0700 [thread overview]
Message-ID: <asz8GKNO9aQANr5E@google.com> (raw)
In-Reply-To: <f7b3a63c-7a1d-445f-b062-4cea5343d266@intel.com>
On Tue, Aug 18, 2026, Xiaoyao Li wrote:
> On 7/23/2026 7:13 AM, Lisa Wang wrote:
> > diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c
> > index 4a48c4b42095..e547ea341ff7 100644
> > --- a/tools/testing/selftests/kvm/lib/kvm_util.c
> > +++ b/tools/testing/selftests/kvm/lib/kvm_util.c
> > @@ -484,8 +484,10 @@ struct kvm_vm *__vm_create(struct vm_shape shape, u32 nr_runnable_vcpus,
> > u64 nr_pages = vm_nr_pages_required(shape.mode, nr_runnable_vcpus,
> > nr_extra_pages);
> > struct userspace_mem_region *slot0;
> > + u64 gmem_flags = 0;
> > struct kvm_vm *vm;
> > - int i, flags;
> > + int flags = 0;
Don't make unnecessary changes. It's not just a "nice to have" thing, e.g. in
this case this results in extra conflicts with other changes.
> > + int i;
> > kvm_set_files_rlimit(nr_runnable_vcpus);
> > @@ -495,14 +497,20 @@ struct kvm_vm *__vm_create(struct vm_shape shape, u32 nr_runnable_vcpus,
> > vm = ____vm_create(shape);
> > /*
> > - * Force GUEST_MEMFD for the primary memory region if necessary, e.g.
> > - * for CoCo VMs that require GUEST_MEMFD backed private memory.
> > + * Force GUEST_MEMFD for the primary memory region if necessary, and
> > + * initialize it as shared if in-place conversion is support, so the
> > + * selftest framework can populate it exactly like other memory
> > + * providers.
> > */
Leave the existing comment as is. The new comment should be anchored to the code
below.
> > - flags = 0;
> > - if (is_guest_memfd_required(shape))
> > + if (is_guest_memfd_required(shape)) {
> > flags |= KVM_MEM_GUEST_MEMFD;
> > + if (kvm_has_gmem_attributes)
> > + gmem_flags |= GUEST_MEMFD_FLAG_INIT_SHARED |
> > + GUEST_MEMFD_FLAG_MMAP;
> > + }
> > - vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, 0, 0, nr_pages, flags);
> > + vm_mem_add(vm, VM_MEM_SRC_ANONYMOUS, 0, 0, nr_pages, flags,
> > + -1, 0, gmem_flags);
> > for (i = 0; i < NR_MEM_REGIONS; i++)
> > vm->memslots[i] = 0;
>
> IMO, this diff belongs to the gmem in-place series.
Yep, you're 100% right. I pushed this to "coco" for now...
diff --git tools/testing/selftests/kvm/lib/kvm_util.c tools/testing/selftests/kvm/lib/kvm_util.c
index 3f559f207408..0c67d964a9aa 100644
--- tools/testing/selftests/kvm/lib/kvm_util.c
+++ tools/testing/selftests/kvm/lib/kvm_util.c
@@ -494,6 +494,7 @@ struct kvm_vm *__vm_create(struct vm_shape shape, u32 nr_runnable_vcpus,
u64 nr_pages = vm_nr_pages_required(shape.mode, nr_runnable_vcpus,
nr_extra_pages);
struct userspace_mem_region *slot0;
+ u64 gmem_flags = 0;
struct kvm_vm *vm;
int i, flags;
@@ -509,10 +510,20 @@ struct kvm_vm *__vm_create(struct vm_shape shape, u32 nr_runnable_vcpus,
* for CoCo VMs that require GUEST_MEMFD backed private memory.
*/
flags = 0;
- if (is_guest_memfd_required(shape))
+ if (is_guest_memfd_required(shape)) {
flags |= KVM_MEM_GUEST_MEMFD;
- vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, 0, 0, nr_pages, flags);
+ /*
+ * Allow mmap() and initialize the gmem instance as SHARED if
+ * in-place conversions are supported, so that the memory can
+ * be populated/initialized like any other memory region.
+ */
+ if (kvm_has_gmem_attributes)
+ gmem_flags |= GUEST_MEMFD_FLAG_INIT_SHARED |
+ GUEST_MEMFD_FLAG_MMAP;
+ }
+
+ vm_mem_add(vm, VM_MEM_SRC_ANONYMOUS, 0, 0, nr_pages, flags, -1, 0, gmem_flags);
for (i = 0; i < NR_MEM_REGIONS; i++)
vm->memslots[i] = 0;
but the entire in-place conversion series may need to be dropped because there's
a potential deadlock, and I don't see an obviously non-awful way to fix it.
[ 2260.466972] ======================================================
[ 2260.473150] WARNING: possible circular locking dependency detected
[ 2260.479329] 7.3.0-smp--ce115a0096358-seanjc-soink #75 Tainted: G U O
[ 2260.486981] ------------------------------------------------------
[ 2260.493161] sev_snp_vmsa_pu/24505 is trying to acquire lock:
[ 2260.498821] ffffffffc01f7900 (sev_cmd_mutex){+.+.}-{4:4}, at: sev_issue_cmd_external_user+0x39/0x60 [ccp]
[ 2260.508387]
but task is already holding lock:
[ 2260.514213] ffff93c9dd1cf070 (mapping.invalidate_lock#4){++++}-{4:4}, at: kvm_gmem_populate+0x18c/0x300 [kvm]
[ 2260.524275]
which lock already depends on the new lock.
[ 2260.532446]
the existing dependency chain (in reverse order) is:
[ 2260.539917]
-> #2 (mapping.invalidate_lock#4){++++}-{4:4}:
[ 2260.546878] down_read+0x3d/0x160
[ 2260.550716] kvm_gmem_fault_user_mapping+0x43/0x180 [kvm]
[ 2260.556663] __do_fault+0x3f/0x110
[ 2260.560588] do_pte_missing+0x515/0x1000
[ 2260.565035] handle_mm_fault+0x7f2/0x1290
[ 2260.569567] do_user_addr_fault+0x47d/0x6c0
[ 2260.574271] exc_page_fault+0x67/0xa0
[ 2260.578458] asm_exc_page_fault+0x26/0x30
[ 2260.582991]
-> #1 (&mm->mmap_lock){++++}-{4:4}:
[ 2260.588997] __might_fault+0x59/0x80
[ 2260.593096] _copy_to_user+0x23/0x60
[ 2260.597197] sev_ioctl_do_platform_status+0x50/0x80 [ccp]
[ 2260.603116] sev_ioctl+0x220/0x2b0 [ccp]
[ 2260.607560] __se_sys_ioctl+0x6d/0xb0
[ 2260.611749] do_syscall_64+0xfe/0x460
[ 2260.615933] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 2260.621506]
-> #0 (sev_cmd_mutex){+.+.}-{4:4}:
[ 2260.627426] __lock_acquire+0x160d/0x2940
[ 2260.631957] lock_acquire+0xf1/0x300
[ 2260.636050] __mutex_lock+0x8f/0xdf0
[ 2260.640147] sev_issue_cmd_external_user+0x39/0x60 [ccp]
[ 2260.645982] sev_gmem_post_populate+0x189/0x230 [kvm_amd]
[ 2260.651901] kvm_gmem_populate+0x1ed/0x300 [kvm]
[ 2260.657066] snp_launch_update+0x1a7/0x250 [kvm_amd]
[ 2260.662551] sev_mem_enc_ioctl+0x371/0x3d0 [kvm_amd]
[ 2260.668036] kvm_vm_ioctl+0x52c/0x580 [kvm]
[ 2260.672761] __se_sys_ioctl+0x6d/0xb0
[ 2260.676946] do_syscall_64+0xfe/0x460
[ 2260.681133] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 2260.686706]
other info that might help us debug this:
[ 2260.694695] Chain exists of:
sev_cmd_mutex --> &mm->mmap_lock --> mapping.invalidate_lock#4
[ 2260.706077] Possible unsafe locking scenario:
[ 2260.711993] CPU0 CPU1
[ 2260.716520] ---- ----
[ 2260.721052] lock(mapping.invalidate_lock#4);
[ 2260.725498] lock(&mm->mmap_lock);
[ 2260.731503] lock(mapping.invalidate_lock#4);
[ 2260.738463] lock(sev_cmd_mutex);
[ 2260.741868]
*** DEADLOCK ***
[ 2260.747778] locks held by sev_snp_vmsa_pu/24505: 3, last CPU#35:
[ 2260.753785] #0: ffff93c9d54bd3a8 (&kvm->lock){+.+.}-{4:4}, at: sev_mem_enc_ioctl+0x73/0x3d0 [kvm_amd]
[ 2260.763083] #1: ffff93c9d54bc0a0 (&kvm->slots_lock){+.+.}-{4:4}, at: snp_launch_update+0x145/0x250 [kvm_amd]
[ 2260.772991] #2: ffff93c9dd1cf070 (mapping.invalidate_lock#4){++++}-{4:4}, at: kvm_gmem_populate+0x18c/0x300 [kvm]
[ 2260.783356]
stack backtrace:
[ 2260.787718] CPU: 35 UID: 0 PID: 24505 Comm: sev_snp_vmsa_pu Tainted: G U O 7.3.0-smp--ce115a0096358-seanjc-soink #75 PREEMPT
[ 2260.800310] Tainted: [U]=USER, [O]=OOT_MODULE
[ 2260.804668] Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026
[ 2260.818127] Call Trace:
[ 2260.820579] <TASK>
[ 2260.822687] dump_stack_lvl+0x54/0x70
[ 2260.826351] print_circular_bug+0x2e4/0x300
[ 2260.830537] check_noncircular+0xf5/0x120
[ 2260.834553] __lock_acquire+0x160d/0x2940
[ 2260.838565] ? __lock_acquire+0x65e/0x2940
[ 2260.842664] ? rcu_is_watching+0x11/0x40
[ 2260.846587] ? trace_sched_exit_tp+0x25/0xb0
[ 2260.850861] lock_acquire+0xf1/0x300
[ 2260.854440] ? sev_issue_cmd_external_user+0x39/0x60 [ccp]
[ 2260.859928] ? lock_is_held_type+0xc7/0x120
[ 2260.864112] ? sev_issue_cmd_external_user+0x39/0x60 [ccp]
[ 2260.869599] __mutex_lock+0x8f/0xdf0
[ 2260.873178] ? sev_issue_cmd_external_user+0x39/0x60 [ccp]
[ 2260.878663] ? pfn_valid+0x89/0x220
[ 2260.882155] ? pfn_valid+0x1fb/0x220
[ 2260.885736] ? lookup_address+0x49/0x70
[ 2260.889577] sev_issue_cmd_external_user+0x39/0x60 [ccp]
[ 2260.894890] sev_gmem_post_populate+0x189/0x230 [kvm_amd]
[ 2260.900289] kvm_gmem_populate+0x1ed/0x300 [kvm]
[ 2260.904938] ? snp_bind_asid+0xd0/0xd0 [kvm_amd]
[ 2260.909561] snp_launch_update+0x1a7/0x250 [kvm_amd]
[ 2260.914528] sev_mem_enc_ioctl+0x371/0x3d0 [kvm_amd]
[ 2260.919493] kvm_vm_ioctl+0x52c/0x580 [kvm]
[ 2260.923706] ? kvm_gmem_ioctl+0x192/0x1e0 [kvm]
[ 2260.928266] __se_sys_ioctl+0x6d/0xb0
[ 2260.931930] do_syscall_64+0xfe/0x460
[ 2260.935595] ? entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 2260.940822] ? trace_irq_disable+0x25/0xc0
[ 2260.944921] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 2260.949972] RIP: 0033:0x474bdb
[ 2260.953031] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
[ 2260.971770] RSP: 002b:00007ffd188ac3f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 2260.979337] RAX: ffffffffffffffda RBX: 0000000028691b30 RCX: 0000000000474bdb
[ 2260.986468] RDX: 00007ffd188ac4a0 RSI: 00000000c008aeba RDI: 0000000000000007
[ 2260.993600] RBP: 0000000000135000 R08: 00000000004d50b8 R09: 00000000004e1b78
[ 2261.000734] R10: 0000000000000002 R11: 0000000000000246 R12: 00007ffd188ac4c0
[ 2261.007867] R13: 0000000000137000 R14: 0000000028693db0 R15: 0000000000137000
[ 2261.015001] </TASK>
next prev parent reply other threads:[~2026-10-12 15:26 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 23:13 [PATCH v14 00/22] TDX KVM selftests Lisa Wang
2026-07-22 23:13 ` [PATCH v14 01/22] KVM: selftests: Add macros to simplify creating VM shapes for non-default types Lisa Wang
2026-08-19 7:44 ` Peter Fang
2026-09-08 16:58 ` Ackerley Tng
2026-07-22 23:13 ` [PATCH v14 02/22] KVM: selftests: Update kvm_init_vm_address_properties() for TDX Lisa Wang
2026-08-13 23:17 ` Edgecombe, Rick P
2026-09-08 17:42 ` Ackerley Tng
2026-07-22 23:13 ` [PATCH v14 03/22] KVM: selftests: Initialize the TDX VM Lisa Wang
2026-07-23 8:44 ` Xiaoyao Li
2026-08-13 23:41 ` Edgecombe, Rick P
2026-08-15 9:17 ` Xiaoyao Li
2026-09-08 8:04 ` Lisa Wang
2026-09-08 18:08 ` Ackerley Tng
2026-09-09 10:00 ` Xiaoyao Li
2026-09-18 1:40 ` Lisa Wang
2026-08-13 23:41 ` Edgecombe, Rick P
2026-08-14 21:18 ` Peter Fang
2026-08-20 8:46 ` Peter Fang
2026-07-22 23:13 ` [PATCH v14 04/22] KVM: selftests: TDX: Use KVM_TDX_CAPABILITIES to validate TDs' attribute configuration Lisa Wang
2026-08-13 23:45 ` Edgecombe, Rick P
2026-09-08 19:06 ` Ackerley Tng
2026-07-22 23:13 ` [PATCH v14 05/22] KVM: selftests: Expose segment definitions to assembly files Lisa Wang
2026-08-13 23:50 ` Edgecombe, Rick P
2026-09-08 19:03 ` Ackerley Tng
2026-07-22 23:13 ` [PATCH v14 06/22] tools: include: Add kbuild.h for assembly structure offsets Lisa Wang
2026-09-08 19:01 ` Ackerley Tng
2026-07-22 23:13 ` [PATCH v14 07/22] KVM: selftests: Introduce structures for TDX guest boot parameters Lisa Wang
2026-07-22 23:13 ` [PATCH v14 08/22] KVM: selftests: Add TDX boot code Lisa Wang
2026-07-23 11:17 ` Xiaoyao Li
2026-08-21 5:16 ` Peter Fang
2026-07-22 23:13 ` [PATCH v14 09/22] KVM: selftests: Expose functions to get default sregs values Lisa Wang
2026-07-23 10:19 ` Xiaoyao Li
2026-08-14 0:44 ` Edgecombe, Rick P
2026-08-14 2:36 ` Xiaoyao Li
2026-08-14 15:14 ` Edgecombe, Rick P
2026-07-22 23:13 ` [PATCH v14 10/22] KVM: selftests: Set up TDX boot code region Lisa Wang
2026-07-23 10:24 ` Xiaoyao Li
2026-08-24 19:27 ` Peter Fang
2026-08-24 20:00 ` Sean Christopherson
2026-08-26 8:31 ` Peter Fang
2026-08-28 20:14 ` Lisa Wang
2026-07-22 23:13 ` [PATCH v14 11/22] KVM: selftests: Set up TDX boot parameters region Lisa Wang
2026-07-23 10:34 ` Xiaoyao Li
2026-08-11 6:32 ` Binbin Wu
2026-08-25 8:14 ` Peter Fang
2026-09-08 19:18 ` Ackerley Tng
2026-09-17 9:12 ` Peter Fang
2026-07-22 23:13 ` [PATCH v14 12/22] KVM: selftests: Require guest_memfd for TDX VMs Lisa Wang
2026-08-11 7:43 ` Binbin Wu
2026-08-14 7:42 ` Xiaoyao Li
2026-09-25 22:04 ` Lisa Wang
2026-07-22 23:13 ` [PATCH v14 13/22] KVM: selftests: Support guest_memfd in-place conversion Lisa Wang
2026-08-18 8:17 ` Xiaoyao Li
2026-10-12 15:26 ` Sean Christopherson [this message]
2026-08-25 21:53 ` Peter Fang
2026-07-22 23:13 ` [PATCH v14 14/22] KVM: selftests: Expose function to allocate vCPU stack Lisa Wang
2026-08-14 8:10 ` Xiaoyao Li
2026-07-22 23:13 ` [PATCH v14 15/22] KVM: selftests: Call KVM_TDX_INIT_VCPU when creating a new TDX vcpu Lisa Wang
2026-08-14 8:32 ` Xiaoyao Li
2026-08-18 8:58 ` Binbin Wu
2026-08-26 21:22 ` Peter Fang
2026-07-22 23:13 ` [PATCH v14 16/22] KVM: selftests: Load per-vCPU guest stack in TDX boot parameters Lisa Wang
2026-08-14 8:39 ` Xiaoyao Li
2026-08-26 22:17 ` Peter Fang
2026-07-22 23:13 ` [PATCH v14 17/22] KVM: selftests: Set entry point for TDX guest code Lisa Wang
2026-08-14 8:43 ` Xiaoyao Li
2026-08-18 9:04 ` Binbin Wu
2026-07-22 23:13 ` [PATCH v14 18/22] KVM: selftests: Add helpers to init TDX memory and finalize VM Lisa Wang
2026-08-17 6:47 ` Xiaoyao Li
2026-08-17 13:52 ` Ackerley Tng
2026-08-18 7:33 ` Xiaoyao Li
2026-09-08 23:12 ` Ackerley Tng
2026-07-22 23:13 ` [PATCH v14 19/22] KVM: selftests: Finalize TD memory as part of kvm_arch_vm_finalize_vcpus Lisa Wang
2026-08-17 7:04 ` Xiaoyao Li
2026-09-08 23:24 ` Ackerley Tng
2026-09-17 9:16 ` Peter Fang
2026-08-27 7:51 ` Peter Fang
2026-07-22 23:13 ` [PATCH v14 20/22] KVM: selftests: Implement MMIO WRITE for the TDX VM Lisa Wang
2026-07-28 22:56 ` Ackerley Tng
2026-08-17 8:56 ` Xiaoyao Li
2026-08-27 9:19 ` Peter Fang
2026-07-22 23:13 ` [PATCH v14 21/22] KVM: selftests: Add ucall support for TDX Lisa Wang
2026-08-17 8:38 ` Xiaoyao Li
2026-08-28 2:06 ` Peter Fang
2026-08-28 2:31 ` Xiaoyao Li
2026-08-28 4:20 ` Peter Fang
2026-08-28 14:18 ` Sean Christopherson
2026-08-31 22:10 ` Peter Fang
2026-09-09 10:59 ` Xiaoyao Li
2026-07-22 23:13 ` [PATCH v14 22/22] KVM: selftests: Add TDX lifecycle test Lisa Wang
2026-08-17 9:04 ` Xiaoyao Li
2026-08-28 4:33 ` Peter Fang
2026-08-13 22:47 ` [PATCH v14 00/22] TDX KVM selftests Edgecombe, Rick P
2026-08-13 23:05 ` Edgecombe, Rick P
2026-08-17 4:19 ` Ackerley Tng
2026-08-17 17:54 ` Edgecombe, Rick P
2026-10-08 21:16 ` Edgecombe, Rick P
2026-10-10 1:28 ` Xiaoyao Li
2026-10-12 15:51 ` Edgecombe, Rick P
2026-08-28 18:30 ` Lisa Wang
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=asz8GKNO9aQANr5E@google.com \
--to=seanjc@google.com \
--cc=ackerleytng@google.com \
--cc=afranji@google.com \
--cc=ajones@ventanamicro.com \
--cc=binbin.wu@linux.intel.com \
--cc=chao.gao@intel.com \
--cc=chenyi.qiang@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=erdemaktas@google.com \
--cc=ira.weiny@intel.com \
--cc=isaku.yamahata@intel.com \
--cc=jmcrey@google.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=oupton@kernel.org \
--cc=pbonzini@redhat.com \
--cc=pratikrajesh.sampat@amd.com \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=runanwang@google.com \
--cc=sagis@google.com \
--cc=shuah@kernel.org \
--cc=wyihan@google.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.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