KVM: x86: KVM_MEM_PCI_HOLE memory

PCIe config space can (depending on the configuration) be quite big but usually is sparsely populated. Guest may scan it by accessing individual device's page which, when device is missing, is supposed to have 'pci hole' semantics: reads return '0xff' and writes get discarded. Compared to the already existing KVM_MEM_READONLY, VMM doesn't need to allocate real memory and stuff it with '0xff'.

Quoted 7 lines · Vitaly Kuznetsov

PCIe config space can (depending on the configuration) be quite big but usually is sparsely populated. Guest may scan it by accessing individual device's page which, when device is missing, is supposed to have 'pci hole' semantics: reads return '0xff' and writes get discarded. Compared to the already existing KVM_MEM_READONLY, VMM doesn't need to allocate real memory and stuff it with '0xff'.

Note that the bus error semantics described should apply to *any* unbacked guest physical addresses, not just addresses in the PCI hole. (Typically, this also applies to the standard local APIC page (0xfee00xxx) when the local APIC is either disabled or in x2APIC mode, which is an area that kvm has had trouble with in the past.)

Quoted 9 lines · Jim Mattson

Quoted 7 lines · Vitaly Kuznetsov

PCIe config space can (depending on the configuration) be quite big but usually is sparsely populated. Guest may scan it by accessing individual device's page which, when device is missing, is supposed to have 'pci hole' semantics: reads return '0xff' and writes get discarded. Compared to the already existing KVM_MEM_READONLY, VMM doesn't need to allocate real memory and stuff it with '0xff'.

Quoted 5 lines

Note that the bus error semantics described should apply to *any* unbacked guest physical addresses, not just addresses in the PCI hole. (Typically, this also applies to the standard local APIC page (0xfee00xxx) when the local APIC is either disabled or in x2APIC mode, which is an area that kvm has had trouble with in the past.)

Well ATM from KVM's POV unbacked -> exit to userspace, right? Not sure what you are suggesting here ...

Quoted 7 lines · Vitaly Kuznetsov

PCIe config space can (depending on the configuration) be quite big but usually is sparsely populated. Guest may scan it by accessing individual device's page which, when device is missing, is supposed to have 'pci hole' semantics: reads return '0xff' and writes get discarded. Compared to the already existing KVM_MEM_READONLY, VMM doesn't need to allocate real memory and stuff it with '0xff'.

Note that the bus error semantics described should apply to *any* unbacked guest physical addresses, not just addresses in the PCI hole. (Typically, this also applies to the standard local APIC page (0xfee00xxx) when the local APIC is either disabled or in x2APIC mode, which is an area that kvm has had trouble with in the past.)

PCIe config space can (depending on the configuration) be quite big but usually is sparsely populated. Guest may scan it by accessing individual device's page which, when device is missing, is supposed to have 'pci hole' semantics: reads return '0xff' and writes get discarded. Compared to the already existing KVM_MEM_READONLY, VMM doesn't need to allocate real memory and stuff it with '0xff'.

Suggested-by Michael S. Tsirkin <[email protected]>

Signed-off-by Vitaly Kuznetsov <[email protected]>

---
 Documentation/virt/kvm/api.rst  | 19 +++++++++++-----
 arch/x86/include/uapi/asm/kvm.h |  1 +
 arch/x86/kvm/mmu/mmu.c          |  5 ++++-
 arch/x86/kvm/mmu/paging_tmpl.h  |  3 +++
 arch/x86/kvm/x86.c              | 10 ++++++---
 include/linux/kvm_host.h        |  7 +++++-
 include/uapi/linux/kvm.h        |  3 ++-
 virt/kvm/kvm_main.c             | 39 +++++++++++++++++++++++++++------
 8 files changed, 68 insertions(+), 19 deletions(-)

Documentation/virt/kvm/api.rst +1 -0

index 644e5326aa50..fbbf533a331b 100644
@@ -1241,6 +1241,7 @@ yet and must be cleared on entry.
   /* for kvm_memory_region::flags */
   #define KVM_MEM_LOG_DIRTY_PAGES	(1UL << 0)
   #define KVM_MEM_READONLY	(1UL << 1)
+  #define KVM_MEM_PCI_HOLE		(1UL << 2)
 
 This ioctl allows the user to create, modify or delete a guest physical
 memory slot.  Bits 0-15 of "slot" specify the slot id and this value

@@ -1268,12 +1269,18 @@ It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr
 be identical.  This allows large pages in the guest to be backed by large

Documentation/virt/kvm/api.rst +0 -0

 When the KVM_CAP_SYNC_MMU capability is available, changes in the backing of
 the memory region are automatically reflected into the guest.  For example, an

arch/x86/include/uapi/asm/kvm.h +1 -0

index 17c5a038f42d..cf80a26d74f5 100644
@@ -48,6 +48,7 @@
 #define __KVM_HAVE_XSAVE
 #define __KVM_HAVE_XCRS
 #define __KVM_HAVE_READONLY_MEM
+#define __KVM_HAVE_PCI_HOLE_MEM
 
 /* Architectural interrupt line count. */
 #define KVM_NR_INTERRUPTS 256

arch/x86/kvm/mmu/mmu.c +4 -1

index 8597e8102636..c2e3a1deafdd 100644
@@ -3253,7 +3253,7 @@ static int kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu, gfn_t gfn,
 		return PG_LEVEL_4K;
 
 	slot = gfn_to_memslot_dirty_bitmap(vcpu, gfn, true);
-	if (!slot)
+	if (!slot || (slot->flags & KVM_MEM_PCI_HOLE))
 		return PG_LEVEL_4K;
 
 	max_level = min(max_level, max_page_level);

@@ -4104,6 +4104,9 @@ static int direct_page_fault(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code,
 
 	slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
 
+	if (!write && slot && (slot->flags & KVM_MEM_PCI_HOLE))
+		return RET_PF_EMULATE;
+
 	if (try_async_pf(vcpu, slot, prefault, gfn, gpa, &pfn, write,
 			 &map_writable))
 		return RET_PF_RETRY;

arch/x86/kvm/mmu/paging_tmpl.h +3 -0

index 5c6a895f67c3..27abd69e69f6 100644
@@ -836,6 +836,9 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gpa_t addr, u32 error_code,
 
 	slot = kvm_vcpu_gfn_to_memslot(vcpu, walker.gfn);
 
+	if (!write_fault && slot && (slot->flags & KVM_MEM_PCI_HOLE))
+		return RET_PF_EMULATE;
+
 	if (try_async_pf(vcpu, slot, prefault, walker.gfn, addr, &pfn,
 			 write_fault, &map_writable))
 		return RET_PF_RETRY;

arch/x86/kvm/x86.c +1 -0

index 95ef62922869..dc312b8bfa05 100644
@@ -3515,6 +3515,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_EXCEPTION_PAYLOAD:
 	case KVM_CAP_SET_GUEST_DEBUG:
 	case KVM_CAP_LAST_CPU:
+	case KVM_CAP_PCI_HOLE_MEM:
 		r = 1;
 		break;
 	case KVM_CAP_SYNC_REGS:

arch/x86/kvm/x86.c +0 -0

 		return;
 
 	/*

include/linux/kvm_host.h +0 -0

index 989afcbe642f..63c2d93ef172 100644

include/linux/kvm_host.h +1 -0

+	}
 }
 
 static inline int memslot_id(struct kvm *kvm, gfn_t gfn)

include/uapi/linux/kvm.h +2 -1

index 2c73dcfb3dbb..59d631cbb71d 100644
@@ -109,6 +109,7 @@ struct kvm_userspace_memory_region {
  */
 #define KVM_MEM_LOG_DIRTY_PAGES	(1UL << 0)
 #define KVM_MEM_READONLY	(1UL << 1)
+#define KVM_MEM_PCI_HOLE		(1UL << 2)
 
 /* for KVM_IRQ_LINE */
 struct kvm_irq_level {

@@ -1034,7 +1035,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_ASYNC_PF_INT 183
 #define KVM_CAP_LAST_CPU 184
 #define KVM_CAP_SMALLER_MAXPHYADDR 185
-
+#define KVM_CAP_PCI_HOLE_MEM 186
 
 #ifdef KVM_CAP_IRQ_ROUTING
 

virt/kvm/kvm_main.c +32 -7

index 2c2c0254c2d8..3f69ae711021 100644
@@ -1107,6 +1107,10 @@ static int check_memory_region_flags(const struct kvm_userspace_memory_region *m
 	valid_flags |= KVM_MEM_READONLY;
 #endif
 
+#ifdef __KVM_HAVE_PCI_HOLE_MEM
+	valid_flags |= KVM_MEM_PCI_HOLE;
+#endif
+
 	if (mem->flags & ~valid_flags)
 		return -EINVAL;
 

@@ -1284,11 +1288,26 @@ int __kvm_set_memory_region(struct kvm *kvm,
 		return -EINVAL;
 	if (mem->guest_phys_addr & (PAGE_SIZE - 1))
 		return -EINVAL;
-	/* We can read the guest memory with __xxx_user() later on. */
-	if ((mem->userspace_addr & (PAGE_SIZE - 1)) ||
-	     !access_ok((void __user *)(unsigned long)mem->userspace_addr,
-			mem->memory_size))
+
+	/*
+	 * KVM_MEM_PCI_HOLE is mutually exclusive with KVM_MEM_READONLY/
+	 * KVM_MEM_LOG_DIRTY_PAGES.
+	 */
+	if ((mem->flags & KVM_MEM_PCI_HOLE) &&
+	    (mem->flags & (KVM_MEM_READONLY | KVM_MEM_LOG_DIRTY_PAGES)))
 		return -EINVAL;
+
+	if (!(mem->flags & KVM_MEM_PCI_HOLE)) {
+		/* We can read the guest memory with __xxx_user() later on. */
+		if ((mem->userspace_addr & (PAGE_SIZE - 1)) ||
+		    !access_ok((void __user *)(unsigned long)mem->userspace_addr,
+			       mem->memory_size))
+			return -EINVAL;
+	} else {
+		if (mem->userspace_addr)
+			return -EINVAL;
+	}
+
 	if (as_id >= KVM_ADDRESS_SPACE_NUM || id >= KVM_MEM_SLOTS_NUM)
 		return -EINVAL;
 	if (mem->guest_phys_addr + mem->memory_size < mem->guest_phys_addr)

@@ -1328,7 +1347,8 @@ int __kvm_set_memory_region(struct kvm *kvm,
 	} else { /* Modify an existing slot. */
 		if ((new.userspace_addr != old.userspace_addr) ||
 		    (new.npages != old.npages) ||
-		    ((new.flags ^ old.flags) & KVM_MEM_READONLY))
+		    ((new.flags ^ old.flags) & KVM_MEM_READONLY) ||
+		    ((new.flags ^ old.flags) & KVM_MEM_PCI_HOLE))
 			return -EINVAL;
 
 		if (new.base_gfn != old.base_gfn)

@@ -1715,13 +1735,13 @@ unsigned long kvm_host_page_size(struct kvm_vcpu *vcpu, gfn_t gfn)
 
 static bool memslot_is_readonly(struct kvm_memory_slot *slot)
 {
-	return slot->flags & KVM_MEM_READONLY;
+	return slot->flags & (KVM_MEM_READONLY | KVM_MEM_PCI_HOLE);
 }
 
 static unsigned long __gfn_to_hva_many(struct kvm_memory_slot *slot, gfn_t gfn,
 				       gfn_t *nr_pages, bool write)
 {
-	if (!slot || slot->flags & KVM_MEMSLOT_INVALID)
+	if (!slot || (slot->flags & (KVM_MEMSLOT_INVALID | KVM_MEM_PCI_HOLE)))
 		return KVM_HVA_ERR_BAD;
 
 	if (memslot_is_readonly(slot) && write)

@@ -2318,6 +2338,11 @@ static int __kvm_read_guest_page(struct kvm_memory_slot *slot, gfn_t gfn,
 	int r;
 	unsigned long addr;
 
+	if (unlikely(slot && (slot->flags & KVM_MEM_PCI_HOLE))) {
+		memset(data, 0xff, len);
+		return 0;
+	}
+
 	addr = gfn_to_hva_memslot_prot(slot, gfn, NULL);
 	if (kvm_is_error_hva(addr))
 		return -EFAULT;

Signature · 1 line

2.25.4

Quoted 34 lines · Vitaly Kuznetsov

PCIe config space can (depending on the configuration) be quite big but usually is sparsely populated. Guest may scan it by accessing individual device's page which, when device is missing, is supposed to have 'pci hole' semantics: reads return '0xff' and writes get discarded. Compared to the already existing KVM_MEM_READONLY, VMM doesn't need to allocate real memory and stuff it with '0xff'.

Suggested-by Michael S. Tsirkin <[email protected]>

Signed-off-by Vitaly Kuznetsov <[email protected]>

---
 Documentation/virt/kvm/api.rst  | 19 +++++++++++-----
 arch/x86/include/uapi/asm/kvm.h |  1 +
 arch/x86/kvm/mmu/mmu.c          |  5 ++++-
 arch/x86/kvm/mmu/paging_tmpl.h  |  3 +++
 arch/x86/kvm/x86.c              | 10 ++++++---
 include/linux/kvm_host.h        |  7 +++++-
 include/uapi/linux/kvm.h        |  3 ++-
 virt/kvm/kvm_main.c             | 39 +++++++++++++++++++++++++++------
 8 files changed, 68 insertions(+), 19 deletions(-)

Documentation/virt/kvm/api.rst +1 -0

index 644e5326aa50..fbbf533a331b 100644
@@ -1241,6 +1241,7 @@ yet and must be cleared on entry.
   /* for kvm_memory_region::flags */
   #define KVM_MEM_LOG_DIRTY_PAGES	(1UL << 0)
   #define KVM_MEM_READONLY	(1UL << 1)
+  #define KVM_MEM_PCI_HOLE		(1UL << 2)
 
 This ioctl allows the user to create, modify or delete a guest physical
 memory slot.  Bits 0-15 of "slot" specify the slot id and this value

@@ -1268,12 +1269,18 @@ It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr
 be identical.  This allows large pages in the guest to be backed by large

Documentation/virt/kvm/api.rst It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr · line 1273

Quoted 10 lines

Documentation/virt/kvm/api.rst +2 -6

 pages in the host.
 
-The flags field supports two flags: KVM_MEM_LOG_DIRTY_PAGES and
-KVM_MEM_READONLY.  The former can be set to instruct KVM to keep track of
-writes to memory within the slot.  See KVM_GET_DIRTY_LOG ioctl to know how to
-use it.  The latter can be set, if KVM_CAP_READONLY_MEM capability allows it,
-to make a new slot read-only.  In this case, writes to this memory will be
-posted to userspace as KVM_EXIT_MMIO exits.
+The flags field supports the following flags: KVM_MEM_LOG_DIRTY_PAGES,
+KVM_MEM_READONLY, KVM_MEM_READONLY:

The second KVM_MEM_READONLY should be KVM_MEM_PCI_HOLE. Or just drop the list here, as they're listed below anyway

Documentation/virt/kvm/api.rst It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr · line 1283

Quoted 10 lines

Documentation/virt/kvm/api.rst +10 -0

+- KVM_MEM_LOG_DIRTY_PAGES can be set to instruct KVM to keep track of writes to
+  memory within the slot.  See KVM_GET_DIRTY_LOG ioctl to know how to use it.
+- KVM_MEM_READONLY can be set, if KVM_CAP_READONLY_MEM capability allows it,
+  to make a new slot read-only.  In this case, writes to this memory will be
+  posted to userspace as KVM_EXIT_MMIO exits.
+- KVM_MEM_PCI_HOLE can be set, if KVM_CAP_PCI_HOLE_MEM capability allows it,
+  to create a new virtual read-only slot which will always return '0xff' when
+  guest reads from it. 'userspace_addr' has to be set to NULL. This flag is
+  mutually exclusive with KVM_MEM_LOG_DIRTY_PAGES/KVM_MEM_READONLY. All writes
+  to this memory will be posted to userspace as KVM_EXIT_MMIO exits.

I see 2/3's of this text is copy+pasted from above, but how about this

- KVM_MEM_LOG_DIRTY_PAGES: log writes. Use KVM_GET_DIRTY_LOG to retreive the log.
- KVM_MEM_READONLY: exit to userspace with KVM_EXIT_MMIO on writes. Only available when KVM_CAP_READONLY_MEM is present.
- KVM_MEM_PCI_HOLE: always return 0xff on reads, exit to userspace with KVM_EXIT_MMIO on writes. Only available when KVM_CAP_PCI_HOLE_MEM is present. When setting the memory region 'userspace_addr' must be NULL. This flag is mutually exclusive with KVM_MEM_LOG_DIRTY_PAGES and with KVM_MEM_READONLY.

Quoted 69 lines

Documentation/virt/kvm/api.rst +0 -0

 When the KVM_CAP_SYNC_MMU capability is available, changes in the backing of
 the memory region are automatically reflected into the guest.  For example, an

arch/x86/include/uapi/asm/kvm.h +1 -0

index 17c5a038f42d..cf80a26d74f5 100644
@@ -48,6 +48,7 @@
 #define __KVM_HAVE_XSAVE
 #define __KVM_HAVE_XCRS
 #define __KVM_HAVE_READONLY_MEM
+#define __KVM_HAVE_PCI_HOLE_MEM
 
 /* Architectural interrupt line count. */
 #define KVM_NR_INTERRUPTS 256

arch/x86/kvm/mmu/mmu.c +4 -1

index 8597e8102636..c2e3a1deafdd 100644
@@ -3253,7 +3253,7 @@ static int kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu, gfn_t gfn,
 		return PG_LEVEL_4K;
 
 	slot = gfn_to_memslot_dirty_bitmap(vcpu, gfn, true);
-	if (!slot)
+	if (!slot || (slot->flags & KVM_MEM_PCI_HOLE))
 		return PG_LEVEL_4K;
 
 	max_level = min(max_level, max_page_level);

@@ -4104,6 +4104,9 @@ static int direct_page_fault(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code,
 
 	slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
 
+	if (!write && slot && (slot->flags & KVM_MEM_PCI_HOLE))
+		return RET_PF_EMULATE;
+
 	if (try_async_pf(vcpu, slot, prefault, gfn, gpa, &pfn, write,
 			 &map_writable))
 		return RET_PF_RETRY;

arch/x86/kvm/mmu/paging_tmpl.h +3 -0

index 5c6a895f67c3..27abd69e69f6 100644
@@ -836,6 +836,9 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gpa_t addr, u32 error_code,
 
 	slot = kvm_vcpu_gfn_to_memslot(vcpu, walker.gfn);
 
+	if (!write_fault && slot && (slot->flags & KVM_MEM_PCI_HOLE))
+		return RET_PF_EMULATE;
+
 	if (try_async_pf(vcpu, slot, prefault, walker.gfn, addr, &pfn,
 			 write_fault, &map_writable))
 		return RET_PF_RETRY;

arch/x86/kvm/x86.c +1 -0

index 95ef62922869..dc312b8bfa05 100644
@@ -3515,6 +3515,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_EXCEPTION_PAYLOAD:
 	case KVM_CAP_SET_GUEST_DEBUG:
 	case KVM_CAP_LAST_CPU:
+	case KVM_CAP_PCI_HOLE_MEM:
 		r = 1;
 		break;
 	case KVM_CAP_SYNC_REGS:

@@ -10115,9 +10116,11 @@ static int kvm_alloc_memslot_metadata(struct kvm_memory_slot *slot,
 		ugfn = slot->userspace_addr >> PAGE_SHIFT;
 		/*
 		 * If the gfn and userspace address are not aligned wrt each

arch/x86/kvm/x86.c static int kvm_alloc_memslot_metadata(struct kvm_memory_slot *slot, · line 10122

Quoted 6 lines

arch/x86/kvm/x86.c +3 -2

-		 * other, disable large page support for this slot.
+		 * other, disable large page support for this slot. Also,
+		 * disable large page support for KVM_MEM_PCI_HOLE slots.
 		 */
-		if ((slot->base_gfn ^ ugfn) & (KVM_PAGES_PER_HPAGE(level) - 1)) {
+		if (slot->flags & KVM_MEM_PCI_HOLE || ((slot->base_gfn ^ ugfn) &

Please add () around the first expression

arch/x86/kvm/x86.c static void kvm_mmu_slot_apply_flags(struct kvm *kvm, · line 10186

Quoted 11 lines

arch/x86/kvm/x86.c +3 -1

+				      (KVM_PAGES_PER_HPAGE(level) - 1))) {
 			unsigned long j;
 
 			for (j = 0; j < lpages; ++j)

@@ -10179,7 +10182,8 @@ static void kvm_mmu_slot_apply_flags(struct kvm *kvm,
 	 * Nothing to do for RO slots or CREATE/MOVE/DELETE of a slot.
 	 * See comments below.
 	 */
-	if ((change != KVM_MR_FLAGS_ONLY) || (new->flags & KVM_MEM_READONLY))
+	if ((change != KVM_MR_FLAGS_ONLY) || (new->flags & KVM_MEM_READONLY) ||
+	    (new->flags & KVM_MEM_PCI_HOLE))

How about

if ((change != KVM_MR_FLAGS_ONLY) ||

     (new->flags & (KVM_MEM_READONLY|KVM_MEM_PCI_HOLE)))

Quoted 13 lines

arch/x86/kvm/x86.c +0 -0

 		return;
 
 	/*

include/linux/kvm_host.h +1 -1

index 989afcbe642f..63c2d93ef172 100644
@@ -1081,7 +1081,12 @@ __gfn_to_memslot(struct kvm_memslots *slots, gfn_t gfn)
 static inline unsigned long
 __gfn_to_hva_memslot(struct kvm_memory_slot *slot, gfn_t gfn)
 {
-	return slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE;
+	if (likely(!(slot->flags & KVM_MEM_PCI_HOLE))) {

include/linux/kvm_host.h __gfn_to_memslot(struct kvm_memslots *slots, gfn_t gfn) · line 1088

Quoted 4 lines

include/linux/kvm_host.h +4 -0

+		return slot->userspace_addr +
+			(gfn - slot->base_gfn) * PAGE_SIZE;
+	} else {
+		BUG();

Debug code you forgot to remove? I see below you've modified __gfn_to_hva_many() to return KVM_HVA_ERR_BAD already when given a PCI hole slot. I think that's the only check we should add.

Quoted 102 lines

include/linux/kvm_host.h +1 -0

+	}
 }
 
 static inline int memslot_id(struct kvm *kvm, gfn_t gfn)

include/uapi/linux/kvm.h +2 -1

index 2c73dcfb3dbb..59d631cbb71d 100644
@@ -109,6 +109,7 @@ struct kvm_userspace_memory_region {
  */
 #define KVM_MEM_LOG_DIRTY_PAGES	(1UL << 0)
 #define KVM_MEM_READONLY	(1UL << 1)
+#define KVM_MEM_PCI_HOLE		(1UL << 2)
 
 /* for KVM_IRQ_LINE */
 struct kvm_irq_level {

@@ -1034,7 +1035,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_ASYNC_PF_INT 183
 #define KVM_CAP_LAST_CPU 184
 #define KVM_CAP_SMALLER_MAXPHYADDR 185
-
+#define KVM_CAP_PCI_HOLE_MEM 186
 
 #ifdef KVM_CAP_IRQ_ROUTING
 

virt/kvm/kvm_main.c +27 -7

index 2c2c0254c2d8..3f69ae711021 100644
@@ -1107,6 +1107,10 @@ static int check_memory_region_flags(const struct kvm_userspace_memory_region *m
 	valid_flags |= KVM_MEM_READONLY;
 #endif
 
+#ifdef __KVM_HAVE_PCI_HOLE_MEM
+	valid_flags |= KVM_MEM_PCI_HOLE;
+#endif
+
 	if (mem->flags & ~valid_flags)
 		return -EINVAL;
 

@@ -1284,11 +1288,26 @@ int __kvm_set_memory_region(struct kvm *kvm,
 		return -EINVAL;
 	if (mem->guest_phys_addr & (PAGE_SIZE - 1))
 		return -EINVAL;
-	/* We can read the guest memory with __xxx_user() later on. */
-	if ((mem->userspace_addr & (PAGE_SIZE - 1)) ||
-	     !access_ok((void __user *)(unsigned long)mem->userspace_addr,
-			mem->memory_size))
+
+	/*
+	 * KVM_MEM_PCI_HOLE is mutually exclusive with KVM_MEM_READONLY/
+	 * KVM_MEM_LOG_DIRTY_PAGES.
+	 */
+	if ((mem->flags & KVM_MEM_PCI_HOLE) &&
+	    (mem->flags & (KVM_MEM_READONLY | KVM_MEM_LOG_DIRTY_PAGES)))
 		return -EINVAL;
+
+	if (!(mem->flags & KVM_MEM_PCI_HOLE)) {
+		/* We can read the guest memory with __xxx_user() later on. */
+		if ((mem->userspace_addr & (PAGE_SIZE - 1)) ||
+		    !access_ok((void __user *)(unsigned long)mem->userspace_addr,
+			       mem->memory_size))
+			return -EINVAL;
+	} else {
+		if (mem->userspace_addr)
+			return -EINVAL;
+	}
+
 	if (as_id >= KVM_ADDRESS_SPACE_NUM || id >= KVM_MEM_SLOTS_NUM)
 		return -EINVAL;
 	if (mem->guest_phys_addr + mem->memory_size < mem->guest_phys_addr)

@@ -1328,7 +1347,8 @@ int __kvm_set_memory_region(struct kvm *kvm,
 	} else { /* Modify an existing slot. */
 		if ((new.userspace_addr != old.userspace_addr) ||
 		    (new.npages != old.npages) ||
-		    ((new.flags ^ old.flags) & KVM_MEM_READONLY))
+		    ((new.flags ^ old.flags) & KVM_MEM_READONLY) ||
+		    ((new.flags ^ old.flags) & KVM_MEM_PCI_HOLE))
 			return -EINVAL;
 
 		if (new.base_gfn != old.base_gfn)

@@ -1715,13 +1735,13 @@ unsigned long kvm_host_page_size(struct kvm_vcpu *vcpu, gfn_t gfn)
 
 static bool memslot_is_readonly(struct kvm_memory_slot *slot)
 {
-	return slot->flags & KVM_MEM_READONLY;
+	return slot->flags & (KVM_MEM_READONLY | KVM_MEM_PCI_HOLE);
 }
 
 static unsigned long __gfn_to_hva_many(struct kvm_memory_slot *slot, gfn_t gfn,
 				       gfn_t *nr_pages, bool write)
 {
-	if (!slot || slot->flags & KVM_MEMSLOT_INVALID)
+	if (!slot || (slot->flags & (KVM_MEMSLOT_INVALID | KVM_MEM_PCI_HOLE)))
 		return KVM_HVA_ERR_BAD;
 
 	if (memslot_is_readonly(slot) && write)

@@ -2318,6 +2338,11 @@ static int __kvm_read_guest_page(struct kvm_memory_slot *slot, gfn_t gfn,
 	int r;
 	unsigned long addr;
 

Quoted 11 lines

virt/kvm/kvm_main.c +5 -0

+	if (unlikely(slot && (slot->flags & KVM_MEM_PCI_HOLE))) {
+		memset(data, 0xff, len);
+		return 0;
+	}
+
 	addr = gfn_to_hva_memslot_prot(slot, gfn, NULL);
 	if (kvm_is_error_hva(addr))
 		return -EFAULT;

Signature · 1 line

2.25.4

I didn't really review this patch, as it's touching lots of x86 mm functions that I didn't want to delve into, but I took a quick look since I was curious about the feature.

This is a continuation of "[PATCH RFC 0/5] KVM: x86: KVM_MEM_ALLONES memory" work:
https://lore.kernel.org/kvm/[email protected]/
and pairs with Julia's "x86/PCI: Use MMCONFIG by default for KVM guests":
https://lore.kernel.org/linux-pci/[email protected]/

PCIe config space can (depending on the configuration) be quite big but usually is sparsely populated. Guest may scan it by accessing individual device's page which, when device is missing, is supposed to have 'pci hole' semantics: reads return '0xff' and writes get discarded.

When testing Linux kernel boot with QEMU q35 VM and direct kernel boot I observed 8193 accesses to PCI hole memory. When such exit is handled in KVM without exiting to userspace, it takes roughly 0.000001 sec. Handling the same exit in userspace is six times slower (0.000006 sec) so the overal; difference is 0.04 sec. This may be significant for 'microvm' ideas.

Note, the same speed can already be achieved by using KVM_MEM_READONLY but doing this would require allocating real memory for all missing devices and e.g. 8192 pages gives us 32mb. This will have to be allocated for each guest separately and for 'microvm' use-cases this is likely a no-go.

Introduce special KVM_MEM_PCI_HOLE memory: userspace doesn't need to back it with real memory, all reads from it are handled inside KVM and return '0xff'. Writes still go to userspace but these should be extremely rare.

The original 'KVM_MEM_ALLONES' idea had additional optimizations: KVM was mapping all 'PCI hole' pages to a single read-only page stuffed with 0xff. This is omitted in this submission as the benefits are unclear:
KVM will have to allocate SPTEs (either on demand or aggressively) and this also consumes time/memory.

We can always take a look at possible
optimizations later.

Vitaly Kuznetsov (3):
KVM: x86: move kvm_vcpu_gfn_to_memslot() out of try_async_pf()
KVM: x86: introduce KVM_MEM_PCI_HOLE memory
KVM: selftests: add KVM_MEM_PCI_HOLE test

 Documentation/virt/kvm/api.rst                |  19 ++-
 arch/x86/include/uapi/asm/kvm.h               |   1 +
 arch/x86/kvm/mmu/mmu.c                        |  19 +--
 arch/x86/kvm/mmu/paging_tmpl.h                |  10 +-
 arch/x86/kvm/x86.c                            |  10 +-
 include/linux/kvm_host.h                      |   7 +-
 include/uapi/linux/kvm.h                      |   3 +-
 tools/testing/selftests/kvm/Makefile          |   1 +
 .../testing/selftests/kvm/include/kvm_util.h  |   1 +
 tools/testing/selftests/kvm/lib/kvm_util.c    |  81 +++++++------
 .../kvm/x86_64/memory_slot_pci_hole.c         | 112 ++++++++++++++++++
 virt/kvm/kvm_main.c                           |  39 ++++--
 12 files changed, 243 insertions(+), 60 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/x86_64/memory_slot_pci_hole.c

Signature · 1 line

2.25.4

Quoted 29 lines · Vitaly Kuznetsov

This is a continuation of "[PATCH RFC 0/5] KVM: x86: KVM_MEM_ALLONES memory" work:
https://lore.kernel.org/kvm/[email protected]/
and pairs with Julia's "x86/PCI: Use MMCONFIG by default for KVM guests":
https://lore.kernel.org/linux-pci/[email protected]/

PCIe config space can (depending on the configuration) be quite big but usually is sparsely populated. Guest may scan it by accessing individual device's page which, when device is missing, is supposed to have 'pci hole' semantics: reads return '0xff' and writes get discarded.

When testing Linux kernel boot with QEMU q35 VM and direct kernel boot I observed 8193 accesses to PCI hole memory. When such exit is handled in KVM without exiting to userspace, it takes roughly 0.000001 sec. Handling the same exit in userspace is six times slower (0.000006 sec) so the overal; difference is 0.04 sec. This may be significant for 'microvm' ideas.

Note, the same speed can already be achieved by using KVM_MEM_READONLY but doing this would require allocating real memory for all missing devices and e.g. 8192 pages gives us 32mb. This will have to be allocated for each guest separately and for 'microvm' use-cases this is likely a no-go.

Introduce special KVM_MEM_PCI_HOLE memory: userspace doesn't need to back it with real memory, all reads from it are handled inside KVM and return '0xff'. Writes still go to userspace but these should be extremely rare.

Quoted 5 lines

The original 'KVM_MEM_ALLONES' idea had additional optimizations: KVM was mapping all 'PCI hole' pages to a single read-only page stuffed with 0xff. This is omitted in this submission as the benefits are unclear:
KVM will have to allocate SPTEs (either on demand or aggressively) and this also consumes time/memory.

Curious about this: if we do it aggressively on the 1st fault, how long does it take to allocate 256 huge page SPTEs? And the amount of memory seems pretty small then, right?

Quoted 36 lines · Michael S. Tsirkin

Quoted 34 lines · Vitaly Kuznetsov

This is a continuation of "[PATCH RFC 0/5] KVM: x86: KVM_MEM_ALLONES memory" work:
https://lore.kernel.org/kvm/[email protected]/
and pairs with Julia's "x86/PCI: Use MMCONFIG by default for KVM guests":
https://lore.kernel.org/linux-pci/[email protected]/

PCIe config space can (depending on the configuration) be quite big but usually is sparsely populated. Guest may scan it by accessing individual device's page which, when device is missing, is supposed to have 'pci hole' semantics: reads return '0xff' and writes get discarded.

When testing Linux kernel boot with QEMU q35 VM and direct kernel boot I observed 8193 accesses to PCI hole memory. When such exit is handled in KVM without exiting to userspace, it takes roughly 0.000001 sec. Handling the same exit in userspace is six times slower (0.000006 sec) so the overal; difference is 0.04 sec. This may be significant for 'microvm' ideas.

Note, the same speed can already be achieved by using KVM_MEM_READONLY but doing this would require allocating real memory for all missing devices and e.g. 8192 pages gives us 32mb. This will have to be allocated for each guest separately and for 'microvm' use-cases this is likely a no-go.

Introduce special KVM_MEM_PCI_HOLE memory: userspace doesn't need to back it with real memory, all reads from it are handled inside KVM and return '0xff'. Writes still go to userspace but these should be extremely rare.

The original 'KVM_MEM_ALLONES' idea had additional optimizations: KVM was mapping all 'PCI hole' pages to a single read-only page stuffed with 0xff. This is omitted in this submission as the benefits are unclear:
KVM will have to allocate SPTEs (either on demand or aggressively) and this also consumes time/memory.

Quoted 3 lines

Curious about this: if we do it aggressively on the 1st fault, how long does it take to allocate 256 huge page SPTEs? And the amount of memory seems pretty small then, right?

Right, this could work but we'll need a 2M region (one per KVM host of course) filled with 0xff-s instead of a single 4k page.

Generally, I'd like to reach an agreement on whether this feature (and the corresponding Julia's patch addding PV feature bit) is worthy. In case it is (meaning it gets merged in this simplest form), we can suggest further improvements. It would also help if firmware (SeaBIOS, OVMF) would start recognizing the PV feature bit too, this way we'll be seeing even bigger improvement and this may or may not be a deal-breaker when it comes to the 'aggressive PTE mapping' idea.

Signature · 1 line

Vitaly

About the feature bit, I am not sure why it's really needed. A single mmio access is cheaper than two io accesses anyway, right? So it makes sense for a kvm guest whether host has this feature or not. We need to be careful and limit to a specific QEMU implementation to avoid tripping up bugs, but it seems more appropriate to check it using pci host IDs.

Quoted 6 lines · Michael S. Tsirkin

About the feature bit, I am not sure why it's really needed. A single mmio access is cheaper than two io accesses anyway, right? So it makes sense for a kvm guest whether host has this feature or not. We need to be careful and limit to a specific QEMU implementation to avoid tripping up bugs, but it seems more appropriate to check it using pci host IDs.

Right, it's just that "running on KVM" is too coarse grained, we just need a way to somehow distinguish between "known/good" and "unknown/buggy" configurations.

Signature · 1 line

Vitaly