2018-04-15 22:01:31

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 00/12] KVM/X86: Introduce a new guest mapping interface

Guest memory can either be directly managed by the kernel (i.e. have a "struct
page") or they can simply live outside kernel control (i.e. do not have a
"struct page"). KVM mostly support these two modes, except in a few places
where the code seems to assume that guest memory must have a "struct page".

This patchset introduces a new mapping interface to map guest memory into host
kernel memory which also supports PFN-based memory (i.e. memory without 'struct
page'). It also converts all offending code to this interface or simply
read/write directly from guest memory.

As far as I can see all offending code is now fixed except the APIC-access page
which I will handle in a seperate patch.

Filippo Sironi (1):
X86/KVM: Handle PFNs outside of kernel reach when touching GPTEs

KarimAllah Ahmed (11):
X86/nVMX: handle_vmon: Read 4 bytes from guest memory
X86/nVMX: handle_vmptrld: Copy the VMCS12 directly from guest memory
X86/nVMX: Update the PML table without mapping and unmapping the page
KVM: Introduce a new guest mapping API
KVM/nVMX: Use kvm_vcpu_map when mapping the L1 MSR bitmap
KVM/nVMX: Use kvm_vcpu_map when mapping the virtual APIC page
KVM/nVMX: Use kvm_vcpu_map when mapping the posted interrupt
descriptor table
KVM/X86: Use kvm_vcpu_map in emulator_cmpxchg_emulated
KVM/X86: hyperv: Use kvm_vcpu_map in synic_clear_sint_msg_pending
KVM/X86: hyperv: Use kvm_vcpu_map in synic_deliver_msg
KVM/nSVM: Use the new mapping API for mapping guest memory

arch/x86/kvm/hyperv.c | 28 ++++-----
arch/x86/kvm/paging_tmpl.h | 38 +++++++++---
arch/x86/kvm/svm.c | 97 +++++++++++++++---------------
arch/x86/kvm/vmx.c | 145 +++++++++++++++------------------------------
arch/x86/kvm/x86.c | 13 ++--
include/linux/kvm_host.h | 9 +++
virt/kvm/kvm_main.c | 50 ++++++++++++++++
7 files changed, 203 insertions(+), 177 deletions(-)

Cc: Paolo Bonzini <[email protected]>
Cc: Radim Krčmář <[email protected]>
Cc: [email protected]
Cc: [email protected]

--
2.7.4



2018-04-15 21:58:47

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 10/12] KVM/X86: hyperv: Use kvm_vcpu_map in synic_clear_sint_msg_pending

Use kvm_vcpu_map in synic_clear_sint_msg_pending since using
kvm_vcpu_gpa_to_page() and kmap() will only work for guest memory that has
a "struct page".

Signed-off-by: KarimAllah Ahmed <[email protected]>
---
v1 -> v2:
- Update to match the new API return codes
---
arch/x86/kvm/hyperv.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
index 98618e3..fc33d8f 100644
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
@@ -158,26 +158,22 @@ static void synic_clear_sint_msg_pending(struct kvm_vcpu_hv_synic *synic,
u32 sint)
{
struct kvm_vcpu *vcpu = synic_to_vcpu(synic);
- struct page *page;
- gpa_t gpa;
+ struct kvm_host_map map;
struct hv_message *msg;
struct hv_message_page *msg_page;

- gpa = synic->msg_page & PAGE_MASK;
- page = kvm_vcpu_gfn_to_page(vcpu, gpa >> PAGE_SHIFT);
- if (is_error_page(page)) {
+ if (kvm_vcpu_map(vcpu, gpa_to_gfn(synic->msg_page), &map)) {
vcpu_err(vcpu, "Hyper-V SynIC can't get msg page, gpa 0x%llx\n",
- gpa);
+ synic->msg_page);
return;
}
- msg_page = kmap_atomic(page);

+ msg_page = map.hva;
msg = &msg_page->sint_message[sint];
msg->header.message_flags.msg_pending = 0;

- kunmap_atomic(msg_page);
- kvm_release_page_dirty(page);
- kvm_vcpu_mark_page_dirty(vcpu, gpa >> PAGE_SHIFT);
+ kvm_vcpu_unmap(&map);
+ kvm_vcpu_mark_page_dirty(vcpu, gpa_to_gfn(synic->msg_page));
}

static void kvm_hv_notify_acked_sint(struct kvm_vcpu *vcpu, u32 sint)
--
2.7.4


2018-04-15 21:58:47

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 11/12] KVM/X86: hyperv: Use kvm_vcpu_map in synic_deliver_msg

Use kvm_vcpu_map in synic_deliver_msg since using kvm_vcpu_gpa_to_page()
and kmap() will only work for guest memory that has a "struct page".

Signed-off-by: KarimAllah Ahmed <[email protected]>
---
v1 -> v2:
- Update to match the new API return codes
---
arch/x86/kvm/hyperv.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
index fc33d8f..668dbd3 100644
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
@@ -580,7 +580,7 @@ static int synic_deliver_msg(struct kvm_vcpu_hv_synic *synic, u32 sint,
struct hv_message *src_msg)
{
struct kvm_vcpu *vcpu = synic_to_vcpu(synic);
- struct page *page;
+ struct kvm_host_map map;
gpa_t gpa;
struct hv_message *dst_msg;
int r;
@@ -590,11 +590,11 @@ static int synic_deliver_msg(struct kvm_vcpu_hv_synic *synic, u32 sint,
return -ENOENT;

gpa = synic->msg_page & PAGE_MASK;
- page = kvm_vcpu_gfn_to_page(vcpu, gpa >> PAGE_SHIFT);
- if (is_error_page(page))
+
+ if (kvm_vcpu_map(vcpu, gpa_to_gfn(gpa), &map))
return -EFAULT;

- msg_page = kmap_atomic(page);
+ msg_page = map.hva;
dst_msg = &msg_page->sint_message[sint];
if (sync_cmpxchg(&dst_msg->header.message_type, HVMSG_NONE,
src_msg->header.message_type) != HVMSG_NONE) {
@@ -611,8 +611,8 @@ static int synic_deliver_msg(struct kvm_vcpu_hv_synic *synic, u32 sint,
else if (r == 0)
r = -EFAULT;
}
- kunmap_atomic(msg_page);
- kvm_release_page_dirty(page);
+
+ kvm_vcpu_unmap(&map);
kvm_vcpu_mark_page_dirty(vcpu, gpa >> PAGE_SHIFT);
return r;
}
--
2.7.4


2018-04-15 21:58:47

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 05/12] KVM: Introduce a new guest mapping API

In KVM, specially for nested guests, there is a dominant pattern of:

=> map guest memory -> do_something -> unmap guest memory

In addition to all this unnecessarily noise in the code due to boiler plate
code, most of the time the mapping function does not properly handle memory
that is not backed by "struct page". This new guest mapping API encapsulate
most of this boiler plate code and also handles guest memory that is not
backed by "struct page".

Keep in mind that memremap is horribly slow, so this mapping API should not
be used for high-frequency mapping operations. But rather for low-frequency
mappings.

Signed-off-by: KarimAllah Ahmed <[email protected]>
---
v1 -> v2:
- Drop the caching optimization (pbonzini)
- Use 'hva' instead of 'kaddr' (pbonzini)
- Return 0/-EINVAL/-EFAULT instead of true/false. -EFAULT will be used for
AMD patch (pbonzini)
- Introduce __kvm_map_gfn which accepts a memory slot and use it (pbonzini)
- Only clear map->hva instead of memsetting the whole structure.
- Drop kvm_vcpu_map_valid since it is no longer used.
- Fix EXPORT_MODULE naming.
---
include/linux/kvm_host.h | 9 +++++++++
virt/kvm/kvm_main.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 59 insertions(+)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index fe4f46b..15b9244 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -204,6 +204,13 @@ enum {
READING_SHADOW_PAGE_TABLES,
};

+struct kvm_host_map {
+ struct page *page;
+ void *hva;
+ kvm_pfn_t pfn;
+ kvm_pfn_t gfn;
+};
+
/*
* Sometimes a large or cross-page mmio needs to be broken up into separate
* exits for userspace servicing.
@@ -700,6 +707,8 @@ struct kvm_memslots *kvm_vcpu_memslots(struct kvm_vcpu *vcpu);
struct kvm_memory_slot *kvm_vcpu_gfn_to_memslot(struct kvm_vcpu *vcpu, gfn_t gfn);
kvm_pfn_t kvm_vcpu_gfn_to_pfn_atomic(struct kvm_vcpu *vcpu, gfn_t gfn);
kvm_pfn_t kvm_vcpu_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn);
+int kvm_vcpu_map(struct kvm_vcpu *vcpu, gpa_t gpa, struct kvm_host_map *map);
+void kvm_vcpu_unmap(struct kvm_host_map *map);
struct page *kvm_vcpu_gfn_to_page(struct kvm_vcpu *vcpu, gfn_t gfn);
unsigned long kvm_vcpu_gfn_to_hva(struct kvm_vcpu *vcpu, gfn_t gfn);
unsigned long kvm_vcpu_gfn_to_hva_prot(struct kvm_vcpu *vcpu, gfn_t gfn, bool *writable);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index c7b2e92..70c3e56 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1631,6 +1631,56 @@ struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn)
}
EXPORT_SYMBOL_GPL(gfn_to_page);

+static int __kvm_map_gfn(struct kvm_memory_slot *slot, gfn_t gfn,
+ struct kvm_host_map *map)
+{
+ kvm_pfn_t pfn;
+ void *hva = NULL;
+ struct page *page = NULL;
+
+ pfn = gfn_to_pfn_memslot(slot, gfn);
+ if (is_error_noslot_pfn(pfn))
+ return -EINVAL;
+
+ if (pfn_valid(pfn)) {
+ page = pfn_to_page(pfn);
+ hva = kmap(page);
+ } else {
+ hva = memremap(pfn_to_hpa(pfn), PAGE_SIZE, MEMREMAP_WB);
+ }
+
+ if (!hva)
+ return -EFAULT;
+
+ map->page = page;
+ map->hva = hva;
+ map->pfn = pfn;
+ map->gfn = gfn;
+
+ return 0;
+}
+
+int kvm_vcpu_map(struct kvm_vcpu *vcpu, gfn_t gfn, struct kvm_host_map *map)
+{
+ return __kvm_map_gfn(kvm_vcpu_gfn_to_memslot(vcpu, gfn), gfn, map);
+}
+EXPORT_SYMBOL_GPL(kvm_vcpu_map);
+
+void kvm_vcpu_unmap(struct kvm_host_map *map)
+{
+ if (!map->hva)
+ return;
+
+ if (map->page)
+ kunmap(map->page);
+ else
+ memunmap(map->hva);
+
+ kvm_release_pfn_dirty(map->pfn);
+ map->hva = NULL;
+}
+EXPORT_SYMBOL_GPL(kvm_vcpu_unmap);
+
struct page *kvm_vcpu_gfn_to_page(struct kvm_vcpu *vcpu, gfn_t gfn)
{
kvm_pfn_t pfn;
--
2.7.4


2018-04-15 21:58:47

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 09/12] KVM/X86: Use kvm_vcpu_map in emulator_cmpxchg_emulated

Use kvm_vcpu_map in emulator_cmpxchg_emulated since using
kvm_vcpu_gpa_to_page() and kmap() will only work for guest memory that has
a "struct page".

Signed-off-by: KarimAllah Ahmed <[email protected]>
---
v1 -> v2:
- Update to match the new API return codes
---
arch/x86/kvm/x86.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4633674..8d08c11 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5162,9 +5162,9 @@ static int emulator_cmpxchg_emulated(struct x86_emulate_ctxt *ctxt,
unsigned int bytes,
struct x86_exception *exception)
{
+ struct kvm_host_map map;
struct kvm_vcpu *vcpu = emul_to_vcpu(ctxt);
gpa_t gpa;
- struct page *page;
char *kaddr;
bool exchanged;

@@ -5181,12 +5181,11 @@ static int emulator_cmpxchg_emulated(struct x86_emulate_ctxt *ctxt,
if (((gpa + bytes - 1) & PAGE_MASK) != (gpa & PAGE_MASK))
goto emul_write;

- page = kvm_vcpu_gfn_to_page(vcpu, gpa >> PAGE_SHIFT);
- if (is_error_page(page))
+ if (kvm_vcpu_map(vcpu, gpa_to_gfn(gpa), &map))
goto emul_write;

- kaddr = kmap_atomic(page);
- kaddr += offset_in_page(gpa);
+ kaddr = map.hva + offset_in_page(gpa);
+
switch (bytes) {
case 1:
exchanged = CMPXCHG_TYPE(u8, kaddr, old, new);
@@ -5203,8 +5202,8 @@ static int emulator_cmpxchg_emulated(struct x86_emulate_ctxt *ctxt,
default:
BUG();
}
- kunmap_atomic(kaddr);
- kvm_release_page_dirty(page);
+
+ kvm_vcpu_unmap(&map);

if (!exchanged)
return X86EMUL_CMPXCHG_FAILED;
--
2.7.4


2018-04-15 21:58:47

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 01/12] X86/nVMX: handle_vmon: Read 4 bytes from guest memory

Read the data directly from guest memory instead instead of the
map->read->unmap sequence. This also avoids using kvm_vcpu_gpa_to_page()
and kmap() which assumes that there is a "struct page" for guest memory.

Suggested-by: Jim Mattson <[email protected]>
Signed-off-by: KarimAllah Ahmed <[email protected]>
---
v1 -> v2:
- Massage commit message a bit.
---
arch/x86/kvm/vmx.c | 14 +++-----------
1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 55ab0ca..77fc1ee 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7672,7 +7672,7 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
{
int ret;
gpa_t vmptr;
- struct page *page;
+ uint32_t revision;
struct vcpu_vmx *vmx = to_vmx(vcpu);
const u64 VMXON_NEEDED_FEATURES = FEATURE_CONTROL_LOCKED
| FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX;
@@ -7718,19 +7718,11 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
return kvm_skip_emulated_instruction(vcpu);
}

- page = kvm_vcpu_gpa_to_page(vcpu, vmptr);
- if (is_error_page(page)) {
+ if (kvm_read_guest(vcpu->kvm, vmptr, &revision, sizeof(revision)) ||
+ revision != VMCS12_REVISION) {
nested_vmx_failInvalid(vcpu);
return kvm_skip_emulated_instruction(vcpu);
}
- if (*(u32 *)kmap(page) != VMCS12_REVISION) {
- kunmap(page);
- kvm_release_page_clean(page);
- nested_vmx_failInvalid(vcpu);
- return kvm_skip_emulated_instruction(vcpu);
- }
- kunmap(page);
- kvm_release_page_clean(page);

vmx->nested.vmxon_ptr = vmptr;
ret = enter_vmx_operation(vcpu);
--
2.7.4


2018-04-15 21:58:47

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 04/12] X86/KVM: Handle PFNs outside of kernel reach when touching GPTEs

From: Filippo Sironi <[email protected]>

cmpxchg_gpte() calls get_user_pages_fast() to retrieve the number of
pages and the respective struct page to map in the kernel virtual
address space.
This doesn't work if get_user_pages_fast() is invoked with a userspace
virtual address that's backed by PFNs outside of kernel reach (e.g., when
limiting the kernel memory with mem= in the command line and using
/dev/mem to map memory).

If get_user_pages_fast() fails, look up the VMA that back the userspace
virtual address, compute the PFN and the physical address, and map it in
the kernel virtual address space with memremap().

Signed-off-by: Filippo Sironi <[email protected]>
Signed-off-by: KarimAllah Ahmed <[email protected]>
---
arch/x86/kvm/paging_tmpl.h | 38 +++++++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 6288e9d..31a37e4 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -141,15 +141,35 @@ static int FNAME(cmpxchg_gpte)(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu,
struct page *page;

npages = get_user_pages_fast((unsigned long)ptep_user, 1, 1, &page);
- /* Check if the user is doing something meaningless. */
- if (unlikely(npages != 1))
- return -EFAULT;
-
- table = kmap_atomic(page);
- ret = CMPXCHG(&table[index], orig_pte, new_pte);
- kunmap_atomic(table);
-
- kvm_release_page_dirty(page);
+ if (likely(npages == 1)) {
+ table = kmap_atomic(page);
+ ret = CMPXCHG(&table[index], orig_pte, new_pte);
+ kunmap_atomic(table);
+
+ kvm_release_page_dirty(page);
+ } else {
+ struct vm_area_struct *vma;
+ unsigned long vaddr = (unsigned long)ptep_user & PAGE_MASK;
+ unsigned long pfn;
+ unsigned long paddr;
+
+ down_read(&current->mm->mmap_sem);
+ vma = find_vma_intersection(current->mm, vaddr, vaddr + PAGE_SIZE);
+ if (!vma || !(vma->vm_flags & VM_PFNMAP)) {
+ up_read(&current->mm->mmap_sem);
+ return -EFAULT;
+ }
+ pfn = ((vaddr - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
+ paddr = pfn << PAGE_SHIFT;
+ table = memremap(paddr, PAGE_SIZE, MEMREMAP_WB);
+ if (!table) {
+ up_read(&current->mm->mmap_sem);
+ return -EFAULT;
+ }
+ ret = CMPXCHG(&table[index], orig_pte, new_pte);
+ memunmap(table);
+ up_read(&current->mm->mmap_sem);
+ }

return (ret != orig_pte);
}
--
2.7.4


2018-04-15 21:58:47

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 12/12] KVM/nSVM: Use the new mapping API for mapping guest memory

Use the new mapping API for mapping guest memory to avoid depending on
"struct page".

Signed-off-by: KarimAllah Ahmed <[email protected]>
---
arch/x86/kvm/svm.c | 97 +++++++++++++++++++++++++++---------------------------
1 file changed, 49 insertions(+), 48 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index b4ade8d..1706eab 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3026,32 +3026,6 @@ static inline bool nested_svm_nmi(struct vcpu_svm *svm)
return false;
}

-static void *nested_svm_map(struct vcpu_svm *svm, u64 gpa, struct page **_page)
-{
- struct page *page;
-
- might_sleep();
-
- page = kvm_vcpu_gfn_to_page(&svm->vcpu, gpa >> PAGE_SHIFT);
- if (is_error_page(page))
- goto error;
-
- *_page = page;
-
- return kmap(page);
-
-error:
- kvm_inject_gp(&svm->vcpu, 0);
-
- return NULL;
-}
-
-static void nested_svm_unmap(struct page *page)
-{
- kunmap(page);
- kvm_release_page_dirty(page);
-}
-
static int nested_svm_intercept_ioio(struct vcpu_svm *svm)
{
unsigned port, size, iopm_len;
@@ -3252,10 +3226,11 @@ static inline void copy_vmcb_control_area(struct vmcb *dst_vmcb, struct vmcb *fr

static int nested_svm_vmexit(struct vcpu_svm *svm)
{
+ int rc;
struct vmcb *nested_vmcb;
struct vmcb *hsave = svm->nested.hsave;
struct vmcb *vmcb = svm->vmcb;
- struct page *page;
+ struct kvm_host_map map;

trace_kvm_nested_vmexit_inject(vmcb->control.exit_code,
vmcb->control.exit_info_1,
@@ -3264,9 +3239,14 @@ static int nested_svm_vmexit(struct vcpu_svm *svm)
vmcb->control.exit_int_info_err,
KVM_ISA_SVM);

- nested_vmcb = nested_svm_map(svm, svm->nested.vmcb, &page);
- if (!nested_vmcb)
+ rc = kvm_vcpu_map(&svm->vcpu, gfn_to_gpa(svm->nested.vmcb), &map);
+ if (rc) {
+ if (rc == -EINVAL)
+ kvm_inject_gp(&svm->vcpu, 0);
return 1;
+ }
+
+ nested_vmcb = map.hva;

/* Exit Guest-Mode */
leave_guest_mode(&svm->vcpu);
@@ -3365,7 +3345,7 @@ static int nested_svm_vmexit(struct vcpu_svm *svm)

mark_all_dirty(svm->vmcb);

- nested_svm_unmap(page);
+ kvm_vcpu_unmap(&map);

nested_svm_uninit_mmu_context(&svm->vcpu);
kvm_mmu_reset_context(&svm->vcpu);
@@ -3423,7 +3403,7 @@ static bool nested_vmcb_checks(struct vmcb *vmcb)
}

static void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,
- struct vmcb *nested_vmcb, struct page *page)
+ struct vmcb *nested_vmcb, struct kvm_host_map *map)
{
if (kvm_get_rflags(&svm->vcpu) & X86_EFLAGS_IF)
svm->vcpu.arch.hflags |= HF_HIF_MASK;
@@ -3503,7 +3483,7 @@ static void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,
svm->vmcb->control.event_inj = nested_vmcb->control.event_inj;
svm->vmcb->control.event_inj_err = nested_vmcb->control.event_inj_err;

- nested_svm_unmap(page);
+ kvm_vcpu_unmap(map);

/* Enter Guest-Mode */
enter_guest_mode(&svm->vcpu);
@@ -3523,17 +3503,23 @@ static void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,

static bool nested_svm_vmrun(struct vcpu_svm *svm)
{
+ int rc;
struct vmcb *nested_vmcb;
struct vmcb *hsave = svm->nested.hsave;
struct vmcb *vmcb = svm->vmcb;
- struct page *page;
+ struct kvm_host_map map;
u64 vmcb_gpa;

vmcb_gpa = svm->vmcb->save.rax;

- nested_vmcb = nested_svm_map(svm, svm->vmcb->save.rax, &page);
- if (!nested_vmcb)
+ rc = kvm_vcpu_map(&svm->vcpu, gfn_to_gpa(vmcb_gpa), &map);
+ if (rc) {
+ if (rc == -EINVAL)
+ kvm_inject_gp(&svm->vcpu, 0);
return false;
+ }
+
+ nested_vmcb = map.hva;

if (!nested_vmcb_checks(nested_vmcb)) {
nested_vmcb->control.exit_code = SVM_EXIT_ERR;
@@ -3541,7 +3527,7 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)
nested_vmcb->control.exit_info_1 = 0;
nested_vmcb->control.exit_info_2 = 0;

- nested_svm_unmap(page);
+ kvm_vcpu_unmap(&map);

return false;
}
@@ -3585,7 +3571,7 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)

copy_vmcb_control_area(hsave, vmcb);

- enter_svm_guest_mode(svm, vmcb_gpa, nested_vmcb, page);
+ enter_svm_guest_mode(svm, vmcb_gpa, nested_vmcb, &map);

return true;
}
@@ -3609,21 +3595,26 @@ static void nested_svm_vmloadsave(struct vmcb *from_vmcb, struct vmcb *to_vmcb)
static int vmload_interception(struct vcpu_svm *svm)
{
struct vmcb *nested_vmcb;
- struct page *page;
+ struct kvm_host_map map;
int ret;

if (nested_svm_check_permissions(svm))
return 1;

- nested_vmcb = nested_svm_map(svm, svm->vmcb->save.rax, &page);
- if (!nested_vmcb)
+ ret = kvm_vcpu_map(&svm->vcpu, gpa_to_gfn(svm->vmcb->save.rax), &map);
+ if (ret) {
+ if (ret == -EINVAL)
+ kvm_inject_gp(&svm->vcpu, 0);
return 1;
+ }
+
+ nested_vmcb = map.hva;

svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
ret = kvm_skip_emulated_instruction(&svm->vcpu);

nested_svm_vmloadsave(nested_vmcb, svm->vmcb);
- nested_svm_unmap(page);
+ kvm_vcpu_unmap(&map);

return ret;
}
@@ -3631,21 +3622,26 @@ static int vmload_interception(struct vcpu_svm *svm)
static int vmsave_interception(struct vcpu_svm *svm)
{
struct vmcb *nested_vmcb;
- struct page *page;
+ struct kvm_host_map map;
int ret;

if (nested_svm_check_permissions(svm))
return 1;

- nested_vmcb = nested_svm_map(svm, svm->vmcb->save.rax, &page);
- if (!nested_vmcb)
+ ret = kvm_vcpu_map(&svm->vcpu, gpa_to_gfn(svm->vmcb->save.rax), &map);
+ if (ret) {
+ if (ret == -EINVAL)
+ kvm_inject_gp(&svm->vcpu, 0);
return 1;
+ }
+
+ nested_vmcb = map.hva;

svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
ret = kvm_skip_emulated_instruction(&svm->vcpu);

nested_svm_vmloadsave(svm->vmcb, nested_vmcb);
- nested_svm_unmap(page);
+ kvm_vcpu_unmap(&map);

return ret;
}
@@ -6152,7 +6148,7 @@ static int svm_pre_leave_smm(struct kvm_vcpu *vcpu, u64 smbase)
{
struct vcpu_svm *svm = to_svm(vcpu);
struct vmcb *nested_vmcb;
- struct page *page;
+ struct kvm_host_map map;
struct {
u64 guest;
u64 vmcb;
@@ -6166,11 +6162,16 @@ static int svm_pre_leave_smm(struct kvm_vcpu *vcpu, u64 smbase)

if (svm_state_save.guest) {
vcpu->arch.hflags &= ~HF_SMM_MASK;
- nested_vmcb = nested_svm_map(svm, svm_state_save.vmcb, &page);
+ if (kvm_vcpu_map(&svm->vcpu, gpa_to_gfn(svm_state_save.vmcb), &map) == -EINVAL)
+ kvm_inject_gp(&svm->vcpu, 0);
+
+ nested_vmcb = map.hva;
+
if (nested_vmcb)
- enter_svm_guest_mode(svm, svm_state_save.vmcb, nested_vmcb, page);
+ enter_svm_guest_mode(svm, svm_state_save.vmcb, nested_vmcb, &map);
else
ret = 1;
+
vcpu->arch.hflags |= HF_SMM_MASK;
}
return ret;
--
2.7.4


2018-04-15 21:58:55

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 08/12] KVM/nVMX: Use kvm_vcpu_map when mapping the posted interrupt descriptor table

Use kvm_vcpu_map when mapping the posted interrupt descriptor table since
using kvm_vcpu_gpa_to_page() and kmap() will only work for guest memory
that has a "struct page".

One additional semantic change is that the virtual host mapping lifecycle
has changed a bit. It now has the same lifetime of the pinning of the
interrupt descriptor table page on the host side.

Signed-off-by: KarimAllah Ahmed <[email protected]>
---
v1 -> v2:
- Do not change the lifecycle of the mapping (pbonzini)
---
arch/x86/kvm/vmx.c | 45 +++++++++++++++------------------------------
1 file changed, 15 insertions(+), 30 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index b55053a..3dd8bb2 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -493,7 +493,7 @@ struct nested_vmx {
*/
struct page *apic_access_page;
struct kvm_host_map virtual_apic_map;
- struct page *pi_desc_page;
+ struct kvm_host_map pi_desc_map;
struct kvm_host_map msr_bitmap_map;

struct pi_desc *pi_desc;
@@ -7807,12 +7807,8 @@ static void free_nested(struct vcpu_vmx *vmx)
vmx->nested.apic_access_page = NULL;
}
kvm_vcpu_unmap(&vmx->nested.virtual_apic_map);
- if (vmx->nested.pi_desc_page) {
- kunmap(vmx->nested.pi_desc_page);
- kvm_release_page_dirty(vmx->nested.pi_desc_page);
- vmx->nested.pi_desc_page = NULL;
- vmx->nested.pi_desc = NULL;
- }
+ kvm_vcpu_unmap(&vmx->nested.pi_desc_map);
+ vmx->nested.pi_desc = NULL;

free_loaded_vmcs(&vmx->nested.vmcs02);
}
@@ -10413,24 +10409,16 @@ static void nested_get_vmcs12_pages(struct kvm_vcpu *vcpu)
}

if (nested_cpu_has_posted_intr(vmcs12)) {
- if (vmx->nested.pi_desc_page) { /* shouldn't happen */
- kunmap(vmx->nested.pi_desc_page);
- kvm_release_page_dirty(vmx->nested.pi_desc_page);
- vmx->nested.pi_desc_page = NULL;
+ map = &vmx->nested.pi_desc_map;
+
+ if (!kvm_vcpu_map(vcpu, gpa_to_gfn(vmcs12->posted_intr_desc_addr), map)) {
+ vmx->nested.pi_desc =
+ (struct pi_desc *)(((void *)map->hva) +
+ offset_in_page(vmcs12->posted_intr_desc_addr));
+ vmcs_write64(POSTED_INTR_DESC_ADDR, pfn_to_hpa(map->pfn) +
+ offset_in_page(vmcs12->posted_intr_desc_addr));
}
- page = kvm_vcpu_gpa_to_page(vcpu, vmcs12->posted_intr_desc_addr);
- if (is_error_page(page))
- return;
- vmx->nested.pi_desc_page = page;
- vmx->nested.pi_desc = kmap(vmx->nested.pi_desc_page);
- vmx->nested.pi_desc =
- (struct pi_desc *)((void *)vmx->nested.pi_desc +
- (unsigned long)(vmcs12->posted_intr_desc_addr &
- (PAGE_SIZE - 1)));
- vmcs_write64(POSTED_INTR_DESC_ADDR,
- page_to_phys(vmx->nested.pi_desc_page) +
- (unsigned long)(vmcs12->posted_intr_desc_addr &
- (PAGE_SIZE - 1)));
+
}
if (nested_vmx_prepare_msr_bitmap(vcpu, vmcs12))
vmcs_set_bits(CPU_BASED_VM_EXEC_CONTROL,
@@ -12067,13 +12055,10 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 exit_reason,
kvm_release_page_dirty(vmx->nested.apic_access_page);
vmx->nested.apic_access_page = NULL;
}
+
kvm_vcpu_unmap(&vmx->nested.virtual_apic_map);
- if (vmx->nested.pi_desc_page) {
- kunmap(vmx->nested.pi_desc_page);
- kvm_release_page_dirty(vmx->nested.pi_desc_page);
- vmx->nested.pi_desc_page = NULL;
- vmx->nested.pi_desc = NULL;
- }
+ kvm_vcpu_unmap(&vmx->nested.pi_desc_map);
+ vmx->nested.pi_desc = NULL;

/*
* We are now running in L2, mmu_notifier will force to reload the
--
2.7.4


2018-04-15 21:59:09

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 03/12] X86/nVMX: Update the PML table without mapping and unmapping the page

Update the PML table without mapping and unmapping the page. This also
avoids using kvm_vcpu_gpa_to_page(..) which assumes that there is a "struct
page" for guest memory.

Signed-off-by: KarimAllah Ahmed <[email protected]>
---
v1 -> v2:
- Use kvm_write_guest_page instead of kvm_write_guest (pbonzini)
- Do not use pointer arithmetic for pml_address (pbonzini)
---
arch/x86/kvm/vmx.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 810ba7a..179061d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -12294,9 +12294,7 @@ static int vmx_write_pml_buffer(struct kvm_vcpu *vcpu)
{
struct vmcs12 *vmcs12;
struct vcpu_vmx *vmx = to_vmx(vcpu);
- gpa_t gpa;
- struct page *page = NULL;
- u64 *pml_address;
+ gpa_t gpa, dst;

if (is_guest_mode(vcpu)) {
WARN_ON_ONCE(vmx->nested.pml_full);
@@ -12316,15 +12314,13 @@ static int vmx_write_pml_buffer(struct kvm_vcpu *vcpu)
}

gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS) & ~0xFFFull;
+ dst = vmcs12->pml_address + sizeof(u64) * vmcs12->guest_pml_index;

- page = kvm_vcpu_gpa_to_page(vcpu, vmcs12->pml_address);
- if (is_error_page(page))
+ if (kvm_write_guest_page(vcpu->kvm, gpa_to_gfn(dst), &gpa,
+ offset_in_page(dst), sizeof(gpa)))
return 0;

- pml_address = kmap(page);
- pml_address[vmcs12->guest_pml_index--] = gpa;
- kunmap(page);
- kvm_release_page_clean(page);
+ vmcs12->guest_pml_index--;
}

return 0;
--
2.7.4


2018-04-15 21:59:18

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 06/12] KVM/nVMX: Use kvm_vcpu_map when mapping the L1 MSR bitmap

Use kvm_vcpu_map when mapping the L1 MSR bitmap since using
kvm_vcpu_gpa_to_page() and kmap() will only work for guest memory that has
a "struct page".

Signed-off-by: KarimAllah Ahmed <[email protected]>
---
v1 -> v2:
- Do not change the lifecycle of the mapping (pbonzini)
---
arch/x86/kvm/vmx.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 179061d..6d335fc 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -494,6 +494,9 @@ struct nested_vmx {
struct page *apic_access_page;
struct page *virtual_apic_page;
struct page *pi_desc_page;
+
+ struct kvm_host_map msr_bitmap_map;
+
struct pi_desc *pi_desc;
bool pi_pending;
u16 posted_intr_nv;
@@ -10513,9 +10516,10 @@ static inline bool nested_vmx_prepare_msr_bitmap(struct kvm_vcpu *vcpu,
struct vmcs12 *vmcs12)
{
int msr;
- struct page *page;
unsigned long *msr_bitmap_l1;
unsigned long *msr_bitmap_l0 = to_vmx(vcpu)->nested.vmcs02.msr_bitmap;
+ struct kvm_host_map *map = &to_vmx(vcpu)->nested.msr_bitmap_map;
+
/*
* pred_cmd & spec_ctrl are trying to verify two things:
*
@@ -10541,11 +10545,10 @@ static inline bool nested_vmx_prepare_msr_bitmap(struct kvm_vcpu *vcpu,
!pred_cmd && !spec_ctrl)
return false;

- page = kvm_vcpu_gpa_to_page(vcpu, vmcs12->msr_bitmap);
- if (is_error_page(page))
+ if (kvm_vcpu_map(vcpu, gpa_to_gfn(vmcs12->msr_bitmap), map))
return false;

- msr_bitmap_l1 = (unsigned long *)kmap(page);
+ msr_bitmap_l1 = (unsigned long *)map->hva;
if (nested_cpu_has_apic_reg_virt(vmcs12)) {
/*
* L0 need not intercept reads for MSRs between 0x800 and 0x8ff, it
@@ -10593,8 +10596,7 @@ static inline bool nested_vmx_prepare_msr_bitmap(struct kvm_vcpu *vcpu,
MSR_IA32_PRED_CMD,
MSR_TYPE_W);

- kunmap(page);
- kvm_release_page_clean(page);
+ kvm_vcpu_unmap(&to_vmx(vcpu)->nested.msr_bitmap_map);

return true;
}
--
2.7.4


2018-04-15 21:59:43

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 02/12] X86/nVMX: handle_vmptrld: Copy the VMCS12 directly from guest memory

Copy the VMCS12 directly from guest memory instead of the map->copy->unmap
sequence. This also avoids using kvm_vcpu_gpa_to_page() and kmap() which
assumes that there is a "struct page" for guest memory.

Signed-off-by: KarimAllah Ahmed <[email protected]>
---
v1 -> v2:
- Massage commit message a bit.
---
arch/x86/kvm/vmx.c | 26 +++++++-------------------
1 file changed, 7 insertions(+), 19 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 77fc1ee..810ba7a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8156,30 +8156,18 @@ static int handle_vmptrld(struct kvm_vcpu *vcpu)
}

if (vmx->nested.current_vmptr != vmptr) {
- struct vmcs12 *new_vmcs12;
- struct page *page;
- page = kvm_vcpu_gpa_to_page(vcpu, vmptr);
- if (is_error_page(page)) {
- nested_vmx_failInvalid(vcpu);
- return kvm_skip_emulated_instruction(vcpu);
- }
- new_vmcs12 = kmap(page);
- if (new_vmcs12->revision_id != VMCS12_REVISION) {
- kunmap(page);
- kvm_release_page_clean(page);
- nested_vmx_failValid(vcpu,
- VMXERR_VMPTRLD_INCORRECT_VMCS_REVISION_ID);
- return kvm_skip_emulated_instruction(vcpu);
- }
-
nested_release_vmcs12(vmx);
+
/*
* Load VMCS12 from guest memory since it is not already
* cached.
*/
- memcpy(vmx->nested.cached_vmcs12, new_vmcs12, VMCS12_SIZE);
- kunmap(page);
- kvm_release_page_clean(page);
+ if (kvm_read_guest(vcpu->kvm, vmptr, vmx->nested.cached_vmcs12,
+ sizeof(*vmx->nested.cached_vmcs12)) ||
+ vmx->nested.cached_vmcs12->revision_id != VMCS12_REVISION) {
+ nested_vmx_failInvalid(vcpu);
+ return kvm_skip_emulated_instruction(vcpu);
+ }

set_current_vmptr(vmx, vmptr);
}
--
2.7.4


2018-04-15 22:00:00

by KarimAllah Ahmed

[permalink] [raw]
Subject: [PATCH v2 07/12] KVM/nVMX: Use kvm_vcpu_map when mapping the virtual APIC page

Use kvm_vcpu_map when mapping the virtual APIC page since using
kvm_vcpu_gpa_to_page() and kmap() will only work for guest memory that has
a "struct page".

One additional semantic change is that the virtual host mapping lifecycle
has changed a bit. It now has the same lifetime of the pinning of the
virtual APIC page on the host side.

Signed-off-by: KarimAllah Ahmed <[email protected]>
---
v1 -> v2:
- Do not change the lifecycle of the mapping (pbonzini)
- Use pfn_to_hpa instead of gfn_to_gpa
---
arch/x86/kvm/vmx.c | 34 +++++++++++-----------------------
1 file changed, 11 insertions(+), 23 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 6d335fc..b55053a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -492,9 +492,8 @@ struct nested_vmx {
* pointers, so we must keep them pinned while L2 runs.
*/
struct page *apic_access_page;
- struct page *virtual_apic_page;
+ struct kvm_host_map virtual_apic_map;
struct page *pi_desc_page;
-
struct kvm_host_map msr_bitmap_map;

struct pi_desc *pi_desc;
@@ -5572,11 +5571,12 @@ static void vmx_complete_nested_posted_interrupt(struct kvm_vcpu *vcpu)

max_irr = find_last_bit((unsigned long *)vmx->nested.pi_desc->pir, 256);
if (max_irr != 256) {
- vapic_page = kmap(vmx->nested.virtual_apic_page);
+ vapic_page = vmx->nested.virtual_apic_map.hva;
+ if (!vapic_page)
+ return;
+
__kvm_apic_update_irr(vmx->nested.pi_desc->pir,
vapic_page, &max_irr);
- kunmap(vmx->nested.virtual_apic_page);
-
status = vmcs_read16(GUEST_INTR_STATUS);
if ((u8)max_irr > ((u8)status & 0xff)) {
status &= ~0xff;
@@ -7806,10 +7806,7 @@ static void free_nested(struct vcpu_vmx *vmx)
kvm_release_page_dirty(vmx->nested.apic_access_page);
vmx->nested.apic_access_page = NULL;
}
- if (vmx->nested.virtual_apic_page) {
- kvm_release_page_dirty(vmx->nested.virtual_apic_page);
- vmx->nested.virtual_apic_page = NULL;
- }
+ kvm_vcpu_unmap(&vmx->nested.virtual_apic_map);
if (vmx->nested.pi_desc_page) {
kunmap(vmx->nested.pi_desc_page);
kvm_release_page_dirty(vmx->nested.pi_desc_page);
@@ -10358,6 +10355,7 @@ static void nested_get_vmcs12_pages(struct kvm_vcpu *vcpu)
{
struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
struct vcpu_vmx *vmx = to_vmx(vcpu);
+ struct kvm_host_map *map;
struct page *page;
u64 hpa;

@@ -10395,11 +10393,7 @@ static void nested_get_vmcs12_pages(struct kvm_vcpu *vcpu)
}

if (nested_cpu_has(vmcs12, CPU_BASED_TPR_SHADOW)) {
- if (vmx->nested.virtual_apic_page) { /* shouldn't happen */
- kvm_release_page_dirty(vmx->nested.virtual_apic_page);
- vmx->nested.virtual_apic_page = NULL;
- }
- page = kvm_vcpu_gpa_to_page(vcpu, vmcs12->virtual_apic_page_addr);
+ map = &vmx->nested.virtual_apic_map;

/*
* If translation failed, VM entry will fail because
@@ -10414,11 +10408,8 @@ static void nested_get_vmcs12_pages(struct kvm_vcpu *vcpu)
* control. But such a configuration is useless, so
* let's keep the code simple.
*/
- if (!is_error_page(page)) {
- vmx->nested.virtual_apic_page = page;
- hpa = page_to_phys(vmx->nested.virtual_apic_page);
- vmcs_write64(VIRTUAL_APIC_PAGE_ADDR, hpa);
- }
+ if (!kvm_vcpu_map(vcpu, gpa_to_gfn(vmcs12->virtual_apic_page_addr), map))
+ vmcs_write64(VIRTUAL_APIC_PAGE_ADDR, pfn_to_hpa(map->pfn));
}

if (nested_cpu_has_posted_intr(vmcs12)) {
@@ -12076,10 +12067,7 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 exit_reason,
kvm_release_page_dirty(vmx->nested.apic_access_page);
vmx->nested.apic_access_page = NULL;
}
- if (vmx->nested.virtual_apic_page) {
- kvm_release_page_dirty(vmx->nested.virtual_apic_page);
- vmx->nested.virtual_apic_page = NULL;
- }
+ kvm_vcpu_unmap(&vmx->nested.virtual_apic_map);
if (vmx->nested.pi_desc_page) {
kunmap(vmx->nested.pi_desc_page);
kvm_release_page_dirty(vmx->nested.pi_desc_page);
--
2.7.4


2018-04-16 12:25:19

by Paolo Bonzini

[permalink] [raw]
Subject: Re: [PATCH v2 03/12] X86/nVMX: Update the PML table without mapping and unmapping the page

On 15/04/2018 23:53, KarimAllah Ahmed wrote:
> + dst = vmcs12->pml_address + sizeof(u64) * vmcs12->guest_pml_index;
>
> - page = kvm_vcpu_gpa_to_page(vcpu, vmcs12->pml_address);
> - if (is_error_page(page))
> + if (kvm_write_guest_page(vcpu->kvm, gpa_to_gfn(dst), &gpa,
> + offset_in_page(dst), sizeof(gpa)))

If you want to use kvm_write_guest_page, this can also be

if (kvm_write_guest_page(vcpu->kvm,
gpa_to_gfn(vmcs12->pml_address), &gpa,
sizeof(gpa) * vmcs12->guest_pml_index,
sizeof(gpa)))

(I should have been more verbose on _why_ I suggested that function; my bad).

Paolo

2018-04-16 12:42:45

by KarimAllah Ahmed

[permalink] [raw]
Subject: Re: [PATCH v2 00/12] KVM/X86: Introduce a new guest mapping interface

On Mon, 2018-04-16 at 13:10 +0200, Paolo Bonzini wrote:
> On 15/04/2018 23:53, KarimAllah Ahmed wrote:
> >
> > Guest memory can either be directly managed by the kernel (i.e. have a "struct
> > page") or they can simply live outside kernel control (i.e. do not have a
> > "struct page"). KVM mostly support these two modes, except in a few places
> > where the code seems to assume that guest memory must have a "struct page".
> >
> > This patchset introduces a new mapping interface to map guest memory into host
> > kernel memory which also supports PFN-based memory (i.e. memory without 'struct
> > page'). It also converts all offending code to this interface or simply
> > read/write directly from guest memory.
> >
> > As far as I can see all offending code is now fixed except the APIC-access page
> > which I will handle in a seperate patch.
>
> I assume the caching will also be a separate patch.

Yup, do you want me to include it in this one? I already have it, I
just thought that I get those bits out first.

>
> It looks good except that I'd squash patches 4 and 9 together.

Yup, makes sense. I should have squashed them when I removed the 
lifecycle change!

Thanks for the review :)

> But I'd like a second set of eyes to look at it.
>
> Thanks,
>
> Paolo
>
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

2018-04-16 14:30:03

by Paolo Bonzini

[permalink] [raw]
Subject: Re: [PATCH v2 00/12] KVM/X86: Introduce a new guest mapping interface

On 15/04/2018 23:53, KarimAllah Ahmed wrote:
> Guest memory can either be directly managed by the kernel (i.e. have a "struct
> page") or they can simply live outside kernel control (i.e. do not have a
> "struct page"). KVM mostly support these two modes, except in a few places
> where the code seems to assume that guest memory must have a "struct page".
>
> This patchset introduces a new mapping interface to map guest memory into host
> kernel memory which also supports PFN-based memory (i.e. memory without 'struct
> page'). It also converts all offending code to this interface or simply
> read/write directly from guest memory.
>
> As far as I can see all offending code is now fixed except the APIC-access page
> which I will handle in a seperate patch.

I assume the caching will also be a separate patch.

It looks good except that I'd squash patches 4 and 9 together. But I'd
like a second set of eyes to look at it.

Thanks,

Paolo

2018-04-16 14:34:28

by Paolo Bonzini

[permalink] [raw]
Subject: Re: [PATCH v2 00/12] KVM/X86: Introduce a new guest mapping interface

On 16/04/2018 14:09, Raslan, KarimAllah wrote:
>> I assume the caching will also be a separate patch.
> Yup, do you want me to include it in this one? I already have it, I
> just thought that I get those bits out first.

It's the same for me.

Paolo

>> It looks good except that I'd squash patches 4 and 9 together.
> Yup, makes sense. I should have squashed them when I removed the 
> lifecycle change!
>
> Thanks for the review :)
>
>> But I'd like a second set of eyes to look at it.


2018-05-15 16:08:37

by Konrad Rzeszutek Wilk

[permalink] [raw]
Subject: Re: [PATCH v2 00/12] KVM/X86: Introduce a new guest mapping interface

On Mon, Apr 16, 2018 at 02:27:13PM +0200, Paolo Bonzini wrote:
> On 16/04/2018 14:09, Raslan, KarimAllah wrote:
> >> I assume the caching will also be a separate patch.
> > Yup, do you want me to include it in this one? I already have it, I
> > just thought that I get those bits out first.
>
> It's the same for me.
>
> Paolo
>
> >> It looks good except that I'd squash patches 4 and 9 together.
> > Yup, makes sense. I should have squashed them when I removed the?
> > lifecycle change!
> >
> > Thanks for the review :)
> >
> >> But I'd like a second set of eyes to look at it.

Did anybody else end up reviewing these patches? And would it make sense
to repost a new version with the #4 and #9 squashed? Thanks.

>

2018-05-22 15:44:22

by KarimAllah Ahmed

[permalink] [raw]
Subject: Re: [PATCH v2 00/12] KVM/X86: Introduce a new guest mapping interface

On Tue, 2018-05-15 at 12:06 -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 16, 2018 at 02:27:13PM +0200, Paolo Bonzini wrote:
> >
> > On 16/04/2018 14:09, Raslan, KarimAllah wrote:
> > >
> > > >
> > > > I assume the caching will also be a separate patch.
> > > Yup, do you want me to include it in this one? I already have it, I
> > > just thought that I get those bits out first.
> >
> > It's the same for me.
> >
> > Paolo
> >
> > >
> > > >
> > > > It looks good except that I'd squash patches 4 and 9 together.
> > > Yup, makes sense. I should have squashed them when I removed the 
> > > lifecycle change!
> > >
> > > Thanks for the review :)
> > >
> > > >
> > > > But I'd like a second set of eyes to look at it.
>
> Did anybody else end up reviewing these patches? And would it make sense
> to repost a new version with the #4 and #9 squashed? Thanks.

No, no second review yet. I will squash and repost a new version.

>
> >
> >
>
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

2018-07-10 12:08:06

by KarimAllah Ahmed

[permalink] [raw]
Subject: Re: [PATCH v2 00/12] KVM/X86: Introduce a new guest mapping interface

On Mon, 2018-04-16 at 13:10 +0200, Paolo Bonzini wrote:
> On 15/04/2018 23:53, KarimAllah Ahmed wrote:
> >
> > Guest memory can either be directly managed by the kernel (i.e. have a "struct
> > page") or they can simply live outside kernel control (i.e. do not have a
> > "struct page"). KVM mostly support these two modes, except in a few places
> > where the code seems to assume that guest memory must have a "struct page".
> >
> > This patchset introduces a new mapping interface to map guest memory into host
> > kernel memory which also supports PFN-based memory (i.e. memory without 'struct
> > page'). It also converts all offending code to this interface or simply
> > read/write directly from guest memory.
> >
> > As far as I can see all offending code is now fixed except the APIC-access page
> > which I will handle in a seperate patch.
>
> I assume the caching will also be a separate patch.
>
> It looks good except that I'd squash patches 4 and 9 together. But I'd
> like a second set of eyes to look at it.

BTW, Why did you want to squash these 2 patches specifically? They are 
very unrelated to me. The only common thing is that they switch from 
code that supports only "struct page" to code that supports PFN only
but this is also common for all other patches.

>
> Thanks,
>
> Paolo
>
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

2018-07-11 10:28:47

by Paolo Bonzini

[permalink] [raw]
Subject: Re: [PATCH v2 00/12] KVM/X86: Introduce a new guest mapping interface

On 10/07/2018 14:06, Raslan, KarimAllah wrote:
> On Mon, 2018-04-16 at 13:10 +0200, Paolo Bonzini wrote:
>> On 15/04/2018 23:53, KarimAllah Ahmed wrote:
>>>
>>> Guest memory can either be directly managed by the kernel (i.e. have a "struct
>>> page") or they can simply live outside kernel control (i.e. do not have a
>>> "struct page"). KVM mostly support these two modes, except in a few places
>>> where the code seems to assume that guest memory must have a "struct page".
>>>
>>> This patchset introduces a new mapping interface to map guest memory into host
>>> kernel memory which also supports PFN-based memory (i.e. memory without 'struct
>>> page'). It also converts all offending code to this interface or simply
>>> read/write directly from guest memory.
>>>
>>> As far as I can see all offending code is now fixed except the APIC-access page
>>> which I will handle in a seperate patch.
>>
>> I assume the caching will also be a separate patch.
>>
>> It looks good except that I'd squash patches 4 and 9 together. But I'd
>> like a second set of eyes to look at it.
>
> BTW, Why did you want to squash these 2 patches specifically? They are 
> very unrelated to me. The only common thing is that they switch from 
> code that supports only "struct page" to code that supports PFN only
> but this is also common for all other patches.

Probably at the time I was thinking they both affect cmpxchg, but really
they are gpte and emulator respectively. Looks like I have 12 more
patches on my review queue then! *ouch*

Paolo

>>
>> Thanks,
>>
>> Paolo
>>
> Amazon Development Center Germany GmbH
> Berlin - Dresden - Aachen
> main office: Krausenstr. 38, 10117 Berlin
> Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
> Ust-ID: DE289237879
> Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
>