From: Patrick Roy <roypat@amazon.co.uk>
To: <seanjc@google.com>, <pbonzini@redhat.com>,
<akpm@linux-foundation.org>, <dwmw@amazon.co.uk>,
<rppt@kernel.org>, <david@redhat.com>
Cc: Patrick Roy <roypat@amazon.co.uk>, <tglx@linutronix.de>,
<mingo@redhat.com>, <bp@alien8.de>, <dave.hansen@linux.intel.com>,
<x86@kernel.org>, <hpa@zytor.com>, <willy@infradead.org>,
<graf@amazon.com>, <derekmn@amazon.com>, <kalyazin@amazon.com>,
<kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-mm@kvack.org>, <dmatlack@google.com>, <tabba@google.com>,
<chao.p.peng@linux.intel.com>, <xmarcalx@amazon.co.uk>
Subject: [RFC PATCH 1/8] kvm: Allow reading/writing gmem using kvm_{read,write}_guest
Date: Tue, 9 Jul 2024 14:20:29 +0100 [thread overview]
Message-ID: <20240709132041.3625501-2-roypat@amazon.co.uk> (raw)
In-Reply-To: <20240709132041.3625501-1-roypat@amazon.co.uk>
If KVM can access guest-private memory without causing a host-kernel
panic (e.g. currently only if the vm type is KVM_SW_PROTECTED_VM), allow
`kvm_{read,write}_guest` to access gfns that are set to "private". If
KVM cannot access guest-private memory (say, because it is running a TDX
VM), prepare a KVM_EXIT_MEMORY_FAULT (if possible) and return -EFAULT.
KVM can only prepare the memory fault exit inside the
`kvm_vcpu_{read,write}_guest` variant, as it needs a vcpu reference to
assign the exit reason to.
KVM accesses guest-private memory via kernel virtual addresses/the
direct map. In the special case of guest_memfd, it does not have to
worry about gfn->pfn mappings being invalidated, since guest_memfd pages
are immovable.
Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
---
include/linux/kvm_host.h | 5 +++
virt/kvm/kvm_main.c | 85 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 90 insertions(+)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 2a6679b46427..8f980aafd5ca 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -2407,6 +2407,11 @@ static inline void kvm_prepare_memory_fault_exit(struct kvm_vcpu *vcpu,
vcpu->run->memory_fault.flags |= KVM_MEMORY_EXIT_FLAG_PRIVATE;
}
+static inline bool kvm_can_access_gmem(struct kvm *kvm)
+{
+ return kvm->arch.vm_type == KVM_X86_SW_PROTECTED_VM;
+}
+
#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn)
{
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 8c7cbc9ec9ee..b3b3de70a4df 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3286,11 +3286,51 @@ static int __kvm_read_guest_page(struct kvm_memory_slot *slot, gfn_t gfn,
return 0;
}
+static int __kvm_read_guest_private_page(struct kvm *kvm,
+ struct kvm_memory_slot *memslot, gfn_t gfn,
+ void *data, int offset, int len)
+{
+ kvm_pfn_t pfn;
+ int r;
+ struct page *page;
+ void *kaddr;
+
+ if (!kvm_can_access_gmem(kvm))
+ return -EFAULT;
+
+ r = kvm_gmem_get_pfn(kvm, memslot, gfn, &pfn, NULL);
+
+ if (r < 0)
+ return -EFAULT;
+
+ page = pfn_to_page(pfn);
+ lock_page(page);
+ kaddr = page_address(page) + offset;
+ memcpy(data, kaddr, len);
+ unlock_page(page);
+ put_page(page);
+ return 0;
+}
+
+static int __kvm_vcpu_read_guest_private_page(struct kvm_vcpu *vcpu,
+ struct kvm_memory_slot *memslot, gfn_t gfn,
+ void *data, int offset, int len)
+{
+ if (!kvm_can_access_gmem(vcpu->kvm)) {
+ kvm_prepare_memory_fault_exit(vcpu, gfn + offset, len, false,
+ false, true);
+ return -EFAULT;
+ }
+ return __kvm_read_guest_private_page(vcpu->kvm, memslot, gfn, data, offset, len);
+}
+
int kvm_read_guest_page(struct kvm *kvm, gfn_t gfn, void *data, int offset,
int len)
{
struct kvm_memory_slot *slot = gfn_to_memslot(kvm, gfn);
+ if (kvm_mem_is_private(kvm, gfn))
+ return __kvm_read_guest_private_page(kvm, slot, gfn, data, offset, len);
return __kvm_read_guest_page(slot, gfn, data, offset, len);
}
EXPORT_SYMBOL_GPL(kvm_read_guest_page);
@@ -3300,6 +3340,8 @@ int kvm_vcpu_read_guest_page(struct kvm_vcpu *vcpu, gfn_t gfn, void *data,
{
struct kvm_memory_slot *slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
+ if (kvm_mem_is_private(vcpu->kvm, gfn))
+ return __kvm_vcpu_read_guest_private_page(vcpu, slot, gfn, data, offset, len);
return __kvm_read_guest_page(slot, gfn, data, offset, len);
}
EXPORT_SYMBOL_GPL(kvm_vcpu_read_guest_page);
@@ -3390,11 +3432,52 @@ static int __kvm_write_guest_page(struct kvm *kvm,
return 0;
}
+static int __kvm_write_guest_private_page(struct kvm *kvm,
+ struct kvm_memory_slot *memslot, gfn_t gfn,
+ const void *data, int offset, int len)
+{
+ kvm_pfn_t pfn;
+ int r;
+ struct page *page;
+ void *kaddr;
+
+ if (!kvm_can_access_gmem(kvm))
+ return -EFAULT;
+
+ r = kvm_gmem_get_pfn(kvm, memslot, gfn, &pfn, NULL);
+
+ if (r < 0)
+ return -EFAULT;
+
+ page = pfn_to_page(pfn);
+ lock_page(page);
+ kaddr = page_address(page) + offset;
+ memcpy(kaddr, data, len);
+ unlock_page(page);
+ put_page(page);
+
+ return 0;
+}
+
+static int __kvm_vcpu_write_guest_private_page(struct kvm_vcpu *vcpu,
+ struct kvm_memory_slot *memslot, gfn_t gfn,
+ const void *data, int offset, int len)
+{
+ if (!kvm_can_access_gmem(vcpu->kvm)) {
+ kvm_prepare_memory_fault_exit(vcpu, gfn + offset, len, true,
+ false, true);
+ return -EFAULT;
+ }
+ return __kvm_write_guest_private_page(vcpu->kvm, memslot, gfn, data, offset, len);
+}
+
int kvm_write_guest_page(struct kvm *kvm, gfn_t gfn,
const void *data, int offset, int len)
{
struct kvm_memory_slot *slot = gfn_to_memslot(kvm, gfn);
+ if (kvm_mem_is_private(kvm, gfn))
+ return __kvm_write_guest_private_page(kvm, slot, gfn, data, offset, len);
return __kvm_write_guest_page(kvm, slot, gfn, data, offset, len);
}
EXPORT_SYMBOL_GPL(kvm_write_guest_page);
@@ -3404,6 +3487,8 @@ int kvm_vcpu_write_guest_page(struct kvm_vcpu *vcpu, gfn_t gfn,
{
struct kvm_memory_slot *slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
+ if (kvm_mem_is_private(vcpu->kvm, gfn))
+ return __kvm_vcpu_write_guest_private_page(vcpu, slot, gfn, data, offset, len);
return __kvm_write_guest_page(vcpu->kvm, slot, gfn, data, offset, len);
}
EXPORT_SYMBOL_GPL(kvm_vcpu_write_guest_page);
base-commit: 771df9ffadb8204e61d3e98f36c5067102aab78f
--
2.45.2
next prev parent reply other threads:[~2024-07-09 13:21 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-09 13:20 [RFC PATCH 0/8] Unmapping guest_memfd from Direct Map Patrick Roy
2024-07-09 13:20 ` Patrick Roy [this message]
2024-07-09 13:20 ` [RFC PATCH 2/8] kvm: use slowpath in gfn_to_hva_cache if memory is private Patrick Roy
2024-07-09 13:20 ` [RFC PATCH 3/8] kvm: pfncache: enlighten about gmem Patrick Roy
2024-07-09 14:36 ` David Woodhouse
2024-07-10 9:49 ` Patrick Roy
2024-07-10 10:20 ` David Woodhouse
2024-07-10 10:46 ` Patrick Roy
2024-07-10 10:50 ` David Woodhouse
2024-07-09 13:20 ` [RFC PATCH 4/8] kvm: x86: support walking guest page tables in gmem Patrick Roy
2024-07-09 13:20 ` [RFC PATCH 5/8] kvm: gmem: add option to remove guest private memory from direct map Patrick Roy
2024-07-10 7:31 ` Mike Rapoport
2024-07-10 9:50 ` Patrick Roy
2024-07-09 13:20 ` [RFC PATCH 6/8] kvm: gmem: Temporarily restore direct map entries when needed Patrick Roy
2024-07-11 6:25 ` Paolo Bonzini
2024-07-09 13:20 ` [RFC PATCH 7/8] mm: secretmem: use AS_INACCESSIBLE to prohibit GUP Patrick Roy
2024-07-09 21:09 ` David Hildenbrand
2024-07-10 7:32 ` Mike Rapoport
2024-07-10 9:50 ` Patrick Roy
2024-07-10 21:14 ` David Hildenbrand
2024-07-09 13:20 ` [RFC PATCH 8/8] kvm: gmem: Allow restricted userspace mappings Patrick Roy
2024-07-09 14:48 ` Fuad Tabba
2024-07-09 21:13 ` David Hildenbrand
2024-07-10 9:51 ` Patrick Roy
2024-07-10 21:12 ` David Hildenbrand
2024-07-10 21:53 ` Sean Christopherson
2024-07-10 21:56 ` David Hildenbrand
2024-07-12 15:59 ` Patrick Roy
2024-07-30 10:15 ` David Hildenbrand
2024-08-01 10:30 ` Patrick Roy
2024-07-22 12:28 ` [RFC PATCH 0/8] Unmapping guest_memfd from Direct Map Vlastimil Babka (SUSE)
2024-07-26 6:55 ` Patrick Roy
2024-07-30 10:17 ` David Hildenbrand
2024-07-26 16:44 ` Yosry Ahmed
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=20240709132041.3625501-2-roypat@amazon.co.uk \
--to=roypat@amazon.co.uk \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=chao.p.peng@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=derekmn@amazon.com \
--cc=dmatlack@google.com \
--cc=dwmw@amazon.co.uk \
--cc=graf@amazon.com \
--cc=hpa@zytor.com \
--cc=kalyazin@amazon.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=tabba@google.com \
--cc=tglx@linutronix.de \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=xmarcalx@amazon.co.uk \
/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