From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1FA84C3DA61 for ; Wed, 24 Jul 2024 16:42:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D7736B0089; Wed, 24 Jul 2024 12:42:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 886C66B008A; Wed, 24 Jul 2024 12:42:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 728586B0092; Wed, 24 Jul 2024 12:42:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 514696B0089 for ; Wed, 24 Jul 2024 12:42:24 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 00635140A9C for ; Wed, 24 Jul 2024 16:42:23 +0000 (UTC) X-FDA: 82375214208.27.3A051C2 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) by imf25.hostedemail.com (Postfix) with ESMTP id 3428DA002B for ; Wed, 24 Jul 2024 16:42:21 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=gXiyGXrm; spf=pass (imf25.hostedemail.com: domain of 37C6hZgsKCAslnvp2wp94yrrzzrwp.nzxwty58-xxv6lnv.z2r@flex--ackerleytng.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=37C6hZgsKCAslnvp2wp94yrrzzrwp.nzxwty58-xxv6lnv.z2r@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721839318; a=rsa-sha256; cv=none; b=MDbtoDsyhEhTOk7b86Lp9uELjEHtX7jWKLdETOTC87gnqsi3jO+YfXOuXAV4w+Sl2eV5Zm WcXxKr5GqazBxpSApCpwwmXfNDVCGbPS7r+Q3wuqRSFyYIRAeBLU7nDbtPlp17eskasjlu xwoKV/PpBkPe5E8yyxsVBjDg2SWmGy8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=gXiyGXrm; spf=pass (imf25.hostedemail.com: domain of 37C6hZgsKCAslnvp2wp94yrrzzrwp.nzxwty58-xxv6lnv.z2r@flex--ackerleytng.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=37C6hZgsKCAslnvp2wp94yrrzzrwp.nzxwty58-xxv6lnv.z2r@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721839318; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:dkim-signature; bh=quXFMjtZMDuExn79bpSog/9LF2Y7O+Ta5z6Tp776il8=; b=f9+mn5EdQwSYJQXyK+2uO3LEmJxTFoOYxDOnMiBfmfPCF4spDtIKGNqJbqroKOZXTMPE0h L2q4lN58+Ss5vKWdKiSksZ41vRQQTdYYBQkWCNMYFZnWDwO1JE1NHVmFuHUeaZvlHsPGPI 4oc0hDcIZ0DnOnsxrYk/m9f3EMwQlSE= Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-70d1df50db2so37554b3a.0 for ; Wed, 24 Jul 2024 09:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1721839341; x=1722444141; darn=kvack.org; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date:from:to :cc:subject:date:message-id:reply-to; bh=quXFMjtZMDuExn79bpSog/9LF2Y7O+Ta5z6Tp776il8=; b=gXiyGXrmVQMVroOoUZoFCA3DhF8DeNqXSqDEFYg8CwlWYw/fnlwJ8kVPrCzi0OvDvG +T9kIvIPOHIvemdNoo41QtiaD0FH7K3UsjnwbXGWU4iETga/Al0N2ia3EnAHdGQGBqev bo97Cj0YbUdWAGDUPHyjZH4riCZg/ohir9pCvTxZGfBAVbes2w3iy9DUzJ7Kazz2iUxw FeZXnrwANZzuZTVOJfM7+a1rhHlMHEpvMXMRsX71uLlOEavVRB9EpckopWwi/BpMpwOD Y8NtSKAaU8Gf7V5wMJVv6+qwujIxexI+bFincKnA7Mcm1V3R8bedJYS5MKVTMfgG7TTh S7cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721839341; x=1722444141; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=quXFMjtZMDuExn79bpSog/9LF2Y7O+Ta5z6Tp776il8=; b=gURY6dA3eWFbFO7ZrNjo9k/YUC0ew4blDT8Qv55/ARd58TF9Qu0QMbOXuMFmrwia6y S2479hA3i7Dza/Ub22EZj8ErXNOlUn+byuqTexIwU3ZNdcOIvoHC4zdlmHp+D3XmqvFy IR1XhKfOo7ReHGXT5ysB8lAuZ+6HmYaJPnT7TVSHelWewlIRLJhmrYrDaqUMX1Qjs+UJ YqCvZjvB8P2eS2nfBm2rzA/2viXd8po5K+rlOJj9xbFC5JXllabD7ROeFnbHCQttisbg uoUsmNybG4ye58C5ZQsXSsIUjf/yVlCbZMNj8xiQN4gjHb8+01XAK0BY0PI2ibEF8rIl lsnQ== X-Forwarded-Encrypted: i=1; AJvYcCUJl/UMoqZ9RKvL1YXvRCN8WtX8A5fjIYoNrFuMOfUgAG+Wq+KSWXVdqQkJDf8VKrTwm2XbzjdOxCanF+MYyYVycUM= X-Gm-Message-State: AOJu0Yy2bZbkKjaX/qRJh/EVU9IOdDhAmuYjTGKWMq/+D6SjHgnFrjXZ DtkcR45BlvT8/ADNp74OdlW3X59J2kES9e0RHDH1zGexrY/dME3fvbV6B1W3nLfMKnJtzkMXQKY fqmGPBJ8YULtRZDssNoa5jA== X-Google-Smtp-Source: AGHT+IHIrwfCPJh1o0JqmPFz3FO0hLjOEEzwgQspX1GMZjdhbr2An4xmUHLxLzB+Uc/ALItH7RCqJY/Tukxlqk7Edg== X-Received: from ackerleytng-ctop.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:13f8]) (user=ackerleytng job=sendgmr) by 2002:a05:6a00:944d:b0:70d:10d8:d050 with SMTP id d2e1a72fcca58-70ea9fd40e7mr7422b3a.0.1721839340518; Wed, 24 Jul 2024 09:42:20 -0700 (PDT) Date: Wed, 24 Jul 2024 16:42:18 +0000 In-Reply-To: (message from Yan Zhao on Thu, 22 Feb 2024 17:19:32 +0800) Mime-Version: 1.0 Message-ID: Subject: Re: [RFC PATCH v5 07/29] KVM: selftests: TDX: Update load_td_memory_region for VM memory backed by guest memfd From: Ackerley Tng To: Yan Zhao Cc: sagis@google.com, linux-kselftest@vger.kernel.org, afranji@google.com, erdemaktas@google.com, isaku.yamahata@intel.com, seanjc@google.com, pbonzini@redhat.com, shuah@kernel.org, pgonda@google.com, haibo1.xu@intel.com, chao.p.peng@linux.intel.com, vannapurve@google.com, runanwang@google.com, vipinsh@google.com, jmattson@google.com, dmatlack@google.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: nhdd3badt17dazmo6sqfexp15nfdd5i4 X-Rspamd-Queue-Id: 3428DA002B X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1721839341-883322 X-HE-Meta: U2FsdGVkX1/hXdnb9OGzmNfN26La0e7Jjb8lK+9GvIf2SlIeW/2S+6jyH+DzCBbsd+F483rbVySxMJdQpve/QRTW1nGkEMTVoe5+tnb0xIBeP43vt0Xm3mIo+zLw1Qi0urNXFskf5U+2PoKK/MinmQq9usiHK5xCAZKMcDtCO2PSvwKlodSiy3YpVcXhkTy3hq7Cs0ZvILkw2NnL++LLnz1aOMgmH+yzHoZtaVrzt7HmFzUZeZhKrxzOkRVddZct2Ki2G8wjGM9V2iGd6vqXADLL9KDF94/5VJkq1LL8EWVaCTmG4TUsyPFayHJSGQernj0f7q9dGc8ya6EIDCtopXO89+DD4Nh8gkw95VJvPI9PBmOHlgllYLjGX5Yy+Zh8Oo6rBW8fpy+SCGFfCogxcS2aLngxsFNDrWBpdH99Q/AsP2mvbWG6sxY+6oTwqeK+Op6VWWl5bw+tX5coxGXUu6vAq/CG+zVHpupmKPKyAH2lpVlHIdzDx/BsMsmdbtitXkhscvf6qMOKCOdbqUAv2JBD9JQcVptVth/n+7YZiP1KMMm/Ld2uczpPN4rKllNlcB38dlNOc/FticbG3jxex0Z/0Cbx597F5wohgSpEK/NzspKud3WDiQCDLGe+kakb8JyDUFLA7VLZ3NCuFNDaHAZ6lrVY6SsbueU0SnADhE66De2w1vMi6Osqyrh4avc8+vfQkOjcWMTMJzNejftkMVUsKrS7d4Q9Onj2OiO3QQstEu6b97Tt0Uw2DyQt5reGiJEuPlfkoVpkbEt+2Rmrb1Qc6e2cfVQG6TFN32oi+VMx6JFxVbXImjzh6rl0FythsWEdWPm+tCDfF1xVwnXshjIpHkEcMdRyMAmRr+bkPaWX+xxA2V3Uu+Ckc+6g24U0NyhZ3Jkc5r6VpQyb8I1ckJt+ODwQd/VMa4L99LyEPU5luniOgrP0xAyHfFnP9wj/t69SUKreNjdgBNa7Wr0 zq9ahLAz d1b7nNTIFWOnFZLlhp4ofThNWYur6mhf52J/10dh/qaA0ee/khdbfoBu/3iD7kA/AwlDGIDEDFPmIJnUzJ5hI2pLDtB3IrsVuROCZ1bhlr9mA9EhRFRStV9DQguWA9XnHaaXt7+ITZqCUpelLY2he9uUYkAe6NzfMJwu09fLMAj23eP9SCp2ZThH05dJHgCu5KacFer/KxZnfUBKrHMhL/RM+qQpuQBrCs6T09yIou4Y483ahEnI/2nrCaj0Z7yDiAMGswvUP6l+kBQppH5A9tVO2h8XzaoydSltwPULkCseJIKehMWOfX1IOTqZe47MAtljNQI+/jt0zAzDINlUQIjHeUsV3BKRbB2gi4+D5RNw3JAWS/BrhCCdWs7dwbZcv7Dsxspu/kntmTrl5TkyHnl/7tfwAw3V4rPT1VOkce2eVfzyu7p1Lgm+Vc6mJjK1Bk7ve540gMgXwfb2d+D76E69OT6RA0KhL+P/0nb1/CTMttGbdVjd47xMEidTb4it4dURhFxRLELmOp1ohcNNchJaFY2/9CwnJsGmOZargAQhyGtlG4A6tNDT0o0ktR3OID+5A6bPi7Q+yV2K081O1wyN89p4s3CwyXF/aolUFD4Gou+I= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000032, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Yan Zhao writes: > On Tue, Dec 12, 2023 at 12:46:22PM -0800, Sagi Shahar wrote: >> From: Ackerley Tng >> >> If guest memory is backed by restricted memfd >> >> + UPM is being used, hence encrypted memory region has to be >> registered >> + Can avoid making a copy of guest memory before getting TDX to >> initialize the memory region >> >> Signed-off-by: Ackerley Tng >> Signed-off-by: Ryan Afranji >> Signed-off-by: Sagi Shahar >> --- >> .../selftests/kvm/lib/x86_64/tdx/tdx_util.c | 41 +++++++++++++++---- >> 1 file changed, 32 insertions(+), 9 deletions(-) >> >> diff --git a/tools/testing/selftests/kvm/lib/x86_64/tdx/tdx_util.c b/tools/testing/selftests/kvm/lib/x86_64/tdx/tdx_util.c >> index 6b995c3f6153..063ff486fb86 100644 >> --- a/tools/testing/selftests/kvm/lib/x86_64/tdx/tdx_util.c >> +++ b/tools/testing/selftests/kvm/lib/x86_64/tdx/tdx_util.c >> @@ -192,6 +192,21 @@ static void tdx_td_finalizemr(struct kvm_vm *vm) >> tdx_ioctl(vm->fd, KVM_TDX_FINALIZE_VM, 0, NULL); >> } >> >> +/* >> + * Other ioctls >> + */ >> + >> +/** >> + * Register a memory region that may contain encrypted data in KVM. >> + */ >> +static void register_encrypted_memory_region( >> + struct kvm_vm *vm, struct userspace_mem_region *region) >> +{ >> + vm_set_memory_attributes(vm, region->region.guest_phys_addr, >> + region->region.memory_size, >> + KVM_MEMORY_ATTRIBUTE_PRIVATE); >> +} >> + >> /* >> * TD creation/setup/finalization >> */ >> @@ -376,30 +391,38 @@ static void load_td_memory_region(struct kvm_vm *vm, >> if (!sparsebit_any_set(pages)) >> return; >> >> + >> + if (region->region.guest_memfd != -1) >> + register_encrypted_memory_region(vm, region); >> + >> sparsebit_for_each_set_range(pages, i, j) { >> const uint64_t size_to_load = (j - i + 1) * vm->page_size; >> const uint64_t offset = >> (i - lowest_page_in_region) * vm->page_size; >> const uint64_t hva = hva_base + offset; >> const uint64_t gpa = gpa_base + offset; >> - void *source_addr; >> + void *source_addr = (void *)hva; >> >> /* >> * KVM_TDX_INIT_MEM_REGION ioctl cannot encrypt memory in place, >> * hence we have to make a copy if there's only one backing >> * memory source >> */ >> - source_addr = mmap(NULL, size_to_load, PROT_READ | PROT_WRITE, >> - MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); >> - TEST_ASSERT( >> - source_addr, >> - "Could not allocate memory for loading memory region"); >> - >> - memcpy(source_addr, (void *)hva, size_to_load); >> + if (region->region.guest_memfd == -1) { >> + source_addr = mmap(NULL, size_to_load, PROT_READ | PROT_WRITE, >> + MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); >> + TEST_ASSERT( >> + source_addr, >> + "Could not allocate memory for loading memory region"); >> + >> + memcpy(source_addr, (void *)hva, size_to_load); >> + memset((void *)hva, 0, size_to_load); >> + } >> >> tdx_init_mem_region(vm, source_addr, gpa, size_to_load); >> >> - munmap(source_addr, size_to_load); >> + if (region->region.guest_memfd == -1) >> + munmap(source_addr, size_to_load); >> } > > For memslot 0, 1, 2, when guest_memfd != -1, > is it possible to also munmap(mmap_start, mmap_size) after finish loading? > Thank you for your review! Did you mean "possible" as in whether it is "correct" to do munmap() for the rest of the earlier memslots containing non-test-code? It is correct because the munmap() just deallocates memory that was recently allocated in mmap() in this same change. The memory set up for the VM is not affected. Hope that answers your question, and here's some further detail, hope this helps too: load_td_memory_region() loads a memory region into a TD by calling the KVM_TDX_INIT_MEM_REGION ioctl, which copies (and encrypts) the data in an existing memory region into TD private memory for the TD to use. In these selftests, we use the KVM selftest framework to set up a TD's memory as if it were a regular VM, and then use this function to copy+encrypt the memory that is already set up for the TD. This lets us re-use most of the code from the KVM selftest framework for TDs, which is extremely useful for setting up page tables, exception handlers, etc for the TD. These key pieces of memory setup are in the memslots with smaller indices, as you pointed out. KVM_TDX_INIT_MEM_REGION ioctl uses the provided gpa and struct kvm to look up the destination address, and uses source_addr as the source address for the copying. If we are not using guest_memfd (region->region.guest_memfd == -1), then we need to make the source and destination address different by copying the contents at the source address somewhere else for the call to tdx_init_mem_region(). That is what the mmap() is doing. This temporary buffer then needs to be freed, hence the munmap(). Without this copying, the destination address for the ioctl's copy would be the same as the source address, since those very same pages are provided in the memslot for this memory region. If we are using guest_memfd, then the destination address for the ioctl's copy will be taken from the guest_memfd, which is already different from the source address, hence we can skip the copying. >> } >> >> -- >> 2.43.0.472.g3155946c3a-goog >> >>