From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D16EC3939A4 for ; Mon, 18 May 2026 20:39:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779136775; cv=none; b=bmvQ2V+0DJ1RqmitUlSz8NRxcrbBUbG55R+nlUBWx2+mLJN/YjFTpwtpY+zhlCGSvY+UXXia72evbdbp0zS/vfBnfxp2azs4MjX/Yg5frqMno+yqQ30AvaAhWPOeVpxnGwZIr01MlA29opPbaSHROBAQzP4XXn1rQG54iYnBeSA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779136775; c=relaxed/simple; bh=1DQgFAuOo/ufJExWgbAin5UszAM9EvUvWON9Wa22hNk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=JOd95ZYa9WO9OTRX6Gv588Zc7XMb8qlp+E69Ol54ZZEiaWO2aqrB7Rv/5bF5H8KkQev9XmoBWt8rYQ0CnY+t93B6CnjyQj9T26+7Z3FeHZY4Oio9pk/aIs0fjuau/6WcW+4xxe+01EmG2/PV16NT3xkvizCitThbiCBiCxLqgLk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=rvaCfsmP; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="rvaCfsmP" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2b2e8bba2e6so42110925ad.1 for ; Mon, 18 May 2026 13:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779136772; x=1779741572; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=cGd6BbSJy5OvNTaNiXv/yILYTZDNFNlp8vbkFDJsHGY=; b=rvaCfsmPyRHOCOqn7UErpvCXq4cbJbTI7vdDUu5cMfoce4rwkN0w3+oTUM/NbF8YY1 ZClhKoXmLgHXv2z2MBZLwC1Q7BOgMz995p6xoXiH1cyAFcfX6V329Qo2tShQ1z3aKb8q ALKJgy8R9Yrjp2NhcmEiZMc4E0WGLbGRTYlLHWdZX0y3NHAH0rKuDWzKgcBs1tNfTatv VfXdbVSJ4yPxPhzhdD6U/XeGby2imNWbz6MZDpI8PmfMNPYs+h+j0CW24QzNsiNOrEvZ G6lPVsj7cIGWblKI4gcuIUt/DcX6jlv4kSYztAD6EveohgVKAw+nRTnRNhs+3EbZlMB7 mnFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779136772; x=1779741572; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cGd6BbSJy5OvNTaNiXv/yILYTZDNFNlp8vbkFDJsHGY=; b=PpraIF0v2Q78p3uq2ZBfiXA8QkZwgwKUCxFz1O5RdCFGqXFb+5I2VAUHZKRuNtCihg DiXsl2C0DtPEuAcwKXfDLoZiXxhhNNolqzHEhOnKW9EdLaeopi1dnasBuDYgoGOJid4u nYPCRNbb8TghOjde3GQOs1xC0ycNtZmdsB7HBILBIde72ItLmYO7EQ9qaKmbbF99bzmQ BN7eja0KgtdEOrQVfSdrodAuaq72F54GnDMXy+1padS5A+80ShXCrOJFeYJAgjYQECAA 2fSBE+BBTel4sOb0aolSW2RpK3VTQgk9KMDhjCLGR8VR55FYX1SrFswBkvnv/DQZyRrG jiJw== X-Forwarded-Encrypted: i=1; AFNElJ/lRZAIkFmkoh9cWXGYND2TeEsEzq2j97zXmZSgLndPqdEXNdigrG8nl2/uRBiZwwfOr0RJd26o5cfk4RNr5xk=@vger.kernel.org X-Gm-Message-State: AOJu0YwFJMX7/e896QnIuaIqGMcp3qCKcBAFiaYkjJ+TSVI87zqJ9DN+ 88C75od3J4kxz8DgQvHFzVurl3ou4Lrlxf8KEv7cRJmOqIu8X/I0daboMRU2DRul4Lie7JTcAdO IFpg/Mg== X-Received: from plhi13.prod.google.com ([2002:a17:903:2ecd:b0:2b2:4f3d:3df4]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:cec7:b0:2b4:5d51:ce96 with SMTP id d9443c01a7336-2bd7e87ed84mr179781255ad.24.1779136771910; Mon, 18 May 2026 13:39:31 -0700 (PDT) Date: Mon, 18 May 2026 13:39:31 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260518070943.2091287-1-ZongYao.Chen@linux.alibaba.com> <20260518070943.2091287-3-ZongYao.Chen@linux.alibaba.com> Message-ID: Subject: Re: [PATCH 2/2] KVM: selftests: Test guest_memfd binding overlap without GPA overlap From: Sean Christopherson To: Ackerley Tng Cc: ZongYao.Chen@linux.alibaba.com, Paolo Bonzini , kvm@vger.kernel.org, Shuah Khan , "Kirill A . Shutemov" , Chao Peng , Xiaoyao Li , Tianjia Zhang , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Mon, May 18, 2026, Ackerley Tng wrote: > ZongYao.Chen@linux.alibaba.com writes: > > > From: Zongyao Chen > > > > The guest_memfd binding overlap test recreates the deleted slot with GPA > > ranges that overlap the still-live slot. KVM rejects those attempts from > > the generic memslot overlap check before reaching kvm_gmem_bind(), so the > > test can pass even if guest_memfd binding overlap detection is broken. > > > > Recreate the slot at its original, non-overlapping GPA and use guest_memfd > > offsets that overlap the front and back halves of the other slot's binding. > > Expand the guest_memfd so the back-half case remains within the file size. > > > > Fixes: 2feabb855df8 ("KVM: selftests: Expand set_memory_region_test to validate guest_memfd()") > > Thanks for fixing this! > > > Signed-off-by: Zongyao Chen > > --- > > .../testing/selftests/kvm/set_memory_region_test.c | 14 +++++++------- > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/tools/testing/selftests/kvm/set_memory_region_test.c b/tools/testing/selftests/kvm/set_memory_region_test.c > > index 9b919a231c93..15607e0bec90 100644 > > --- a/tools/testing/selftests/kvm/set_memory_region_test.c > > +++ b/tools/testing/selftests/kvm/set_memory_region_test.c > > @@ -510,7 +510,7 @@ static void test_add_overlapping_private_memory_regions(void) > > Shall we rename this to test_bind_overlapping_guest_memfd_offsets to > make it clearer? Hmm, not if we make the change additive (see blelow). > Perhaps also update the pr_info() to "Testing binding to overlapping > guest_memfd offsets\n". > > > > > vm = vm_create_barebones_type(KVM_X86_SW_PROTECTED_VM); > > > > - memfd = vm_create_guest_memfd(vm, MEM_REGION_SIZE * 4, 0); > > + memfd = vm_create_guest_memfd(vm, MEM_REGION_SIZE * 6, 0); > > I think this technically only needs to be MEM_REGION_SIZE * 5 for this > test to work. > > > > > vm_set_user_memory_region2(vm, MEM_REGION_SLOT, KVM_MEM_GUEST_MEMFD, > > MEM_REGION_GPA, MEM_REGION_SIZE * 2, 0, memfd, 0); > > @@ -526,19 +526,19 @@ static void test_add_overlapping_private_memory_regions(void) > > vm_set_user_memory_region2(vm, MEM_REGION_SLOT, KVM_MEM_GUEST_MEMFD, > > MEM_REGION_GPA, 0, NULL, -1, 0); > > When I re-read this I was wondering why we created and removed the first > memslot. Was it meant as a confidence check that set_memory_region works > with the given MEM_REGION_GPA? Perhaps we could add a comment/pr_info() > to check that. Rather than "fix" the check, why not have both? > > - /* Overlap the front half of the other slot. */ > > + /* Overlap the front half of the other slot's guest_memfd binding. */ > > r = __vm_set_user_memory_region2(vm, MEM_REGION_SLOT, KVM_MEM_GUEST_MEMFD, > > - MEM_REGION_GPA * 2 - MEM_REGION_SIZE, > > + MEM_REGION_GPA, > > MEM_REGION_SIZE * 2, > > - 0, memfd, 0); > > + 0, memfd, MEM_REGION_SIZE); > > TEST_ASSERT(r == -1 && errno == EEXIST, "%s", > > "Overlapping guest_memfd() bindings should fail with EEXIST"); > > > > - /* And now the back half of the other slot. */ > > + /* And now the back half of the other slot's guest_memfd binding. */ > > r = __vm_set_user_memory_region2(vm, MEM_REGION_SLOT, KVM_MEM_GUEST_MEMFD, > > - MEM_REGION_GPA * 2 + MEM_REGION_SIZE, > > + MEM_REGION_GPA, > > MEM_REGION_SIZE * 2, > > - 0, memfd, 0); > > + 0, memfd, MEM_REGION_SIZE * 3); > > TEST_ASSERT(r == -1 && errno == EEXIST, "%s", > > "Overlapping guest_memfd() bindings should fail with EEXIST"); > > > > Since this test program is meant to test set_memory_region, should we be > retaining the original test? The original test is wrong in that it > doesn't test guest_memfd's binding, but it does test that > set_memory_region returns -EEXIST on overlapping GPAs. > > Perhaps to just test overlapping GPAs we can use anonymous memory > instead of guest_memfd. Eh, I see no harm in having both. E.g. if we do this, then we don't have to explain why we're not testing the other case :-) diff --git a/tools/testing/selftests/kvm/set_memory_region_test.c b/tools/testing/selftests/kvm/set_memory_region_test.c index 9b919a231c93..283392bcc3a0 100644 --- a/tools/testing/selftests/kvm/set_memory_region_test.c +++ b/tools/testing/selftests/kvm/set_memory_region_test.c @@ -510,7 +510,7 @@ static void test_add_overlapping_private_memory_regions(void) vm = vm_create_barebones_type(KVM_X86_SW_PROTECTED_VM); - memfd = vm_create_guest_memfd(vm, MEM_REGION_SIZE * 4, 0); + memfd = vm_create_guest_memfd(vm, MEM_REGION_SIZE * 5, 0); vm_set_user_memory_region2(vm, MEM_REGION_SLOT, KVM_MEM_GUEST_MEMFD, MEM_REGION_GPA, MEM_REGION_SIZE * 2, 0, memfd, 0); @@ -542,6 +542,26 @@ static void test_add_overlapping_private_memory_regions(void) TEST_ASSERT(r == -1 && errno == EEXIST, "%s", "Overlapping guest_memfd() bindings should fail with EEXIST"); + /* + * Repeat the overlap tests, but so that there is overlap in the + * guest_memfd bindings (i.e. in guest_memfd file offsets), but _not_ + * in the GPA space. Regardless of where there's overlap, KVM should + * return -EEXIST. + */ + r = __vm_set_user_memory_region2(vm, MEM_REGION_SLOT, KVM_MEM_GUEST_MEMFD, + MEM_REGION_GPA, + MEM_REGION_SIZE * 2, + 0, memfd, MEM_REGION_SIZE); + TEST_ASSERT(r == -1 && errno == EEXIST, "%s", + "Overlapping guest_memfd() bindings should fail with EEXIST"); + + /* And now the back half of the other slot's guest_memfd binding. */ + r = __vm_set_user_memory_region2(vm, MEM_REGION_SLOT, KVM_MEM_GUEST_MEMFD, + MEM_REGION_GPA, + MEM_REGION_SIZE * 2, + 0, memfd, MEM_REGION_SIZE * 3); + TEST_ASSERT(r == -1 && errno == EEXIST, "%s", + "Overlapping guest_memfd() bindings should fail with EEXIST"); close(memfd); kvm_vm_free(vm); }