KVM: arm64: Rewrite page-table code and fault handling
Will Deacon
maintainercover KVM: arm64: Rewrite page-table code and fault handling
Hi all,
This fairly hefty series rewrites all of KVM's page-table code on arm64.
You might be wondering why I've done that, and I can ensure you that it wasn't for fun. No, some of the benefits of rewriting this code are as follows:
* The hypervisor stage-1 and guest stage-2 page tables can now be configured at runtime, independently of each other and of the host kernel's stage-1 configuration. This allows us to remove the extended idmap at EL2 entirely and accept large guest IPA sizes without worrying about the number of levels in use by the host.
* The code is smaller. We're losing ~500 lines with this series, and that's in spite of a bunch of kerneldoc being added for the new API.
* It paves the way for managing the stage-2 page-tables at EL2 on nVHE systems, which is a crucial part of the Android "Protected KVM" project, which aims to isolate guest memory from the host kernel.
* In some cases, the new walker allows us to reduce the number of walks being performed. For example, user_mem_abort() no longer has to walk the page-table twice when handling permission faults.
The series is based on kvmarm/next, plus these two series I sent previously:
- memcache cleanups:
https://lore.kernel.org/r/[email protected]
- Early S2 fault fixes:
https://lore.kernel.org/r/[email protected]
It will conflict with Sean's memcache stuff in -next, but that shouldn't be too hard to sort out.
I've tried to split up the conversion of kvm/mmu.c into reviewable chunks, mopping up all the leftover code at the end. That means bisection will warn about unused functions in the middle of the series, but I think it makes the changes considerably more focussed and easier to review.
In terms of testing, I've done the usual Debian installer type things, but Quentin has also written targetted guest code [1] which we used to exercise dirty logging page-table collapse and coalescing. I also wrote a silly hack where KVM allocated two S2 page-tables for each VM; one using the old code and one using the new code. At PSCI SYSTEM_OFF, a walker walked each page-table, using siphash to create a hash of all of the entries (but masking out the address fields in table entries). After the walk, the hashes were compared for the two tables and I have so far been unable to trigger a mismatch. That said, I haven't really kicked the tyres outside of defconfig.
To make things easier to work with, I've put the whole lot on a branch here:
https://android-kvm.googlesource.com/linux/+/refs/heads/topic/pgtable
Cheers,
Will
[1] https://android-kvm.googlesource.com/misc/+/refs/heads/qperret/pgtable-test
--->8
Quentin Perret (4):
KVM: arm64: Add support for stage-2 write-protect in generic
page-table
KVM: arm64: Convert write-protect operation to generic page-table API
KVM: arm64: Add support for stage-2 cache flushing in generic
page-table
KVM: arm64: Convert memslot cache-flushing code to generic page-table
API
Will Deacon (16):
KVM: arm64: Add stand-alone page-table walker infrastructure
KVM: arm64: Add support for creating kernel-agnostic stage-1 page
tables
KVM: arm64: Use generic allocator for hyp stage-1 page-tables
KVM: arm64: Add support for creating kernel-agnostic stage-2 page
tables
KVM: arm64: Add support for stage-2 map()/unmap() in generic
page-table
KVM: arm64: Convert kvm_phys_addr_ioremap() to generic page-table API
KVM: arm64: Convert kvm_set_spte_hva() to generic page-table API
KVM: arm64: Convert unmap_stage2_range() to generic page-table API
KVM: arm64: Add support for stage-2 page-aging in generic page-table
KVM: arm64: Convert page-aging and access faults to generic page-table
API
KVM: arm64: Add support for relaxing stage-2 perms in generic
page-table code
KVM: arm64: Convert user_mem_abort() to generic page-table API
KVM: arm64: Check the cookie instead of the pgd when modifying
page-table
KVM: arm64: Remove unused page-table code
KVM: arm64: Remove unused 'pgd' field from 'struct kvm_s2_mmu'
KVM: arm64: Don't constrain maximum IPA size based on host
configuration
arch/arm64/include/asm/kvm_host.h | 2 +- arch/arm64/include/asm/kvm_mmu.h | 219 +--- arch/arm64/include/asm/kvm_pgtable.h | 269 ++++ arch/arm64/include/asm/pgtable-hwdef.h | 23 - arch/arm64/include/asm/pgtable-prot.h | 19 - arch/arm64/include/asm/stage2_pgtable.h | 215 ---- arch/arm64/kvm/Makefile | 2 +- arch/arm64/kvm/mmu.c | 1549 +++-------------------- arch/arm64/kvm/pgtable.c | 906 +++++++++++++ arch/arm64/kvm/reset.c | 38 +- 10 files changed, 1340 insertions(+), 1902 deletions(-) create mode 100644 arch/arm64/include/asm/kvm_pgtable.h create mode 100644 arch/arm64/kvm/pgtable.c
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 1/20 KVM: arm64: Add stand-alone page-table walker infrastructure
The KVM page-table code is intricately tied into the kernel page-table code and re-uses the pte/pmd/pud/p4d/pgd macros directly in an attempt to reduce code duplication. Unfortunately, the reality is that there is an awful lot of code required to make this work, and at the end of the day you're limited to creating page-tables with the same configuration as the host kernel. Furthermore, lifting the page-table code to run directly at EL2 on a non-VHE system (as we plan to to do in future patches) is practically impossible due to the number of dependencies it has on the core kernel.
Introduce a framework for walking Armv8 page-tables configured independently from the host kernel.
--- arch/arm64/include/asm/kvm_pgtable.h | 93 +++++++++ arch/arm64/kvm/Makefile | 2 +- arch/arm64/kvm/pgtable.c | 300 +++++++++++++++++++++++++++ 3 files changed, 394 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/include/asm/kvm_pgtable.h create mode 100644 arch/arm64/kvm/pgtable.c
arch/arm64/include/asm/kvm_pgtable.h new file +93 -0
@@ -0,0 +1,93 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* +* Copyright (C) 2020 Google LLC +* Author: Will Deacon <[email protected]> +*/ + +#ifndef __ARM64_KVM_PGTABLE_H__ +#define __ARM64_KVM_PGTABLE_H__ + +#include <linux/bits.h> +#include <linux/kvm_host.h> +#include <linux/types.h> + +typedef u64 kvm_pte_t ; + +/** +* enum kvm_pgtable_prot - Page-table permissions and attributes. +* @KVM_PGTABLE_PROT_R: Read permission. +* @KVM_PGTABLE_PROT_W: Write permission. +* @KVM_PGTABLE_PROT_X: Execute permission. +* @KVM_PGTABLE_PROT_DEVICE: Device attributes. +*/ +enum kvm_pgtable_prot { +KVM_PGTABLE_PROT_R =BIT (0 ), +KVM_PGTABLE_PROT_W =BIT (1 ), +KVM_PGTABLE_PROT_X =BIT (2 ), + +KVM_PGTABLE_PROT_DEVICE =BIT (3 ), +}; + +/** +* enum kvm_pgtable_walk_flags - Flags to control a depth-first page-table walk. +* @KVM_PGTABLE_WALK_LEAF: Visit leaf entries, including invalid +* entries. +* @KVM_PGTABLE_WALK_TABLE_PRE: Visit table entries before their +* children. +* @KVM_PGTABLE_WALK_TABLE_POST: Visit table entries after their +* children. +*/ +enum kvm_pgtable_walk_flags { +KVM_PGTABLE_WALK_LEAF =BIT (0 ), +KVM_PGTABLE_WALK_TABLE_PRE =BIT (1 ), +KVM_PGTABLE_WALK_TABLE_POST =BIT (2 ), +}; + +typedef int (*kvm_pgtable_visitor_fn_t )(u64 addr,u64 end,u32 level, +kvm_pte_t *ptep, +enum kvm_pgtable_walk_flags flag, +void *const arg); + +/** +* struct kvm_pgtable_walker - Hook into a page-table walk. +* @cb: Callback function to invoke during the walk. +* @arg: Argument passed to the callback function. +* @flags: Bitwise-OR of flags to identify the entry types on which to +* invoke the callback function. +*/ +struct kvm_pgtable_walker { +const kvm_pgtable_visitor_fn_t cb; +void *const arg; +const enum kvm_pgtable_walk_flags flags; +}; + +/** +* kvm_pgtable_get_pgd_phys() - Get physical pgd pointer for a page-table. +* @cookie: Opaque cookie allocated by kvm_pgtable_*_alloc_cookie(). +* +* Return: The physical address of the page-table base (pgd). +*/ +u64 kvm_pgtable_get_pgd_phys (void *cookie); + +/** +* kvm_pgtable_walk() - Walk a page-table. +* @cookie: Opaque cookie allocated by kvm_pgtable_*_alloc_cookie(). +* @addr: Input address for the start of the walk. +* @size: Size of the range to walk. +* @walker: Walker callback description. +* +* The walker will walk the page-table entries corresponding to the input +* address range specified, visiting entries according to the walker flags. +* Invalid entries are treated as leaf entries. Leaf entries are reloaded +* after invoking the walker callback, allowing the walker to descend into +* a newly installed table. +* +* Returning a negative error code from the walker callback function will +* terminate the walk immediately with the same error code. +* +* Return: 0 on success, negative error code on failure. +*/ +int kvm_pgtable_walk (void *cookie,u64 addr,u64 size, +struct kvm_pgtable_walker *walker); + +#endif /* __ARM64_KVM_PGTABLE_H__ */
arch/arm64/kvm/Makefile +1 -1
@@ -12,7 +12,7 @@ obj-$(CONFIG_KVM) += hyp/ kvm-y := $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o \ $(KVM)/vfio.o $(KVM)/irqchip.o \ - arm.o mmu.o mmio.o psci.o perf.o hypercalls.o pvtime.o \ + arm.o mmu.o mmio.o pgtable.o psci.o perf.o hypercalls.o pvtime.o \ inject_fault.o regmap.o va_layout.o hyp.o handle_exit.o \ guest.o debug.o reset.o sys_regs.o \ vgic-sys-reg-v3.o fpsimd.o pmu.o \
arch/arm64/kvm/pgtable.c new file +300 -0
300 lines not on this page · raw message
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 2/20 KVM: arm64: Add support for creating kernel-agnostic stage-1 page tables
In reply to Will DeaconThe generic page-table walker is pretty useless as it stands, because it doesn't understand enough to allocate anything. Teach it about stage-1 page-tables, and hook up an API for allocating these for the hypervisor at EL2.
--- arch/arm64/include/asm/kvm_pgtable.h | 33 ++++++ arch/arm64/kvm/pgtable.c | 145 +++++++++++++++++++++++++++ 2 files changed, 178 insertions(+)
arch/arm64/include/asm/kvm_pgtable.h +33 -0
@@ -61,6 +61,39 @@ struct kvm_pgtable_walker {const enum kvm_pgtable_walk_flags flags; }; +/** +* kvm_pgtable_hyp_alloc_cookie() - Allocate a hypervisor stage-1 page-table. +* @va_bits: Maximum virtual address bits. +* +* Return: An opaque cookie which can be used to manipulate the page-table. +*/ +void *kvm_pgtable_hyp_alloc_cookie (u32 va_bits); + +/** +* kvm_pgtable_hyp_free_cookie() - Free an unused hypervisor stage-1 page-table. +* @cookie: Opaque cookie allocated by kvm_pgtable_hyp_alloc_cookie(). +* +* The page-table is assumed to be unreachable by any hardware walkers prior +* to freeing and therefore no TLB invalidation is performed. +*/ +void kvm_pgtable_hyp_free_cookie (void *cookie); + +/** +* kvm_pgtable_hyp_map() - Install a mapping in a hypervisor stage-1 page-table. +* @cookie: Opaque cookie allocated by kvm_pgtable_hyp_alloc_cookie(). +* @addr: Virtual address at which to place the mapping. +* @size: Size of the mapping. +* @phys: Physical address of the memory to map. +* @prot: Permissions and attributes for the mapping. +* +* If device attributes are not explicitly requested in @prot, then the +* mapping will be normal, cacheable. +* +* Return: 0 on success, negative error code on failure. +*/ +int kvm_pgtable_hyp_map (void *cookie,u64 addr,u64 size,u64 phys, +enum kvm_pgtable_prot prot); +/** * kvm_pgtable_get_pgd_phys() - Get physical pgd pointer for a page-table. * @cookie: Opaque cookie allocated by kvm_pgtable_*_alloc_cookie().
arch/arm64/kvm/pgtable.c +145 -0
159 lines not on this page · raw message
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 02/20] KVM: arm64: Add support for creating kernel-agnostic stage-1 page tables
Hey Will,
Quoted 30 lines · Will Deacon
arch/arm64/kvm/pgtable.c +30
-0+void *kvm_pgtable_hyp_alloc_cookie (u32 va_bits) +{ +struct kvm_pgtable *pgt =kzalloc (sizeof (*pgt),GFP_KERNEL ); + +if (!pgt) +return NULL ; + + pgt->ia_bits = va_bits; + pgt->start_level =kvm_start_level (va_bits); + + pgt->pgd = (kvm_pte_t *)get_zeroed_page (GFP_KERNEL ); +if (!pgt->pgd) { +kfree (pgt); + pgt =NULL ; + } + +return pgt; +} + +static int hyp_free_walker (u64 addr,u64 end,u32 level,kvm_pte_t *ptep, +enum kvm_pgtable_walk_flags flag,void *const arg) +{ +free_page ((unsigned long )kvm_pte_follow (*ptep)); +return 0 ; +} + +void kvm_pgtable_hyp_free_cookie (void *cookie) +{ +size_t pgd_sz; +struct kvm_pgtable *pgt = cookie;
arch/arm64/kvm/pgtable.c int kvm_pgtable_walk(void *cookie, u64 addr, u64 size, · line 437
Quoted 10 lines
arch/arm64/kvm/pgtable.c +10
-0+struct kvm_pgtable_walker walker = { + .cb = hyp_free_walker, + .flags =KVM_PGTABLE_WALK_TABLE_POST , + }; + +if (kvm_pgtable_walk (cookie,0 ,BIT (pgt->ia_bits), &walker)) +kvm_err ("Failed to free page-table pages\n" ); + + pgd_sz =kvm_pgd_pages (pgt) *PAGE_SIZE ; +free_pages_exact (pgt->pgd, pgd_sz);
Given that the pgd is unconditionally a single page for the stage 1 case (as per kvm_pgtable_hyp_alloc_cookie() above), should we simplify this to a simple free_page()? Or did you want to factorize this with the stage 2 free path?
Review
Quoted 2 lines
(quoted diff) +2
-0+ kfree(pgt); +}
Cheers,
Quentin
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 02/20] KVM: arm64: Add support for creating kernel-agnostic stage-1 page tables
Quoted 40 lines · Quentin Perret
Hey Will,
Quoted 37 lines · Will Deacon
arch/arm64/kvm/pgtable.c +37
-0+void *kvm_pgtable_hyp_alloc_cookie (u32 va_bits) +{ +struct kvm_pgtable *pgt =kzalloc (sizeof (*pgt),GFP_KERNEL ); + +if (!pgt) +return NULL ; + + pgt->ia_bits = va_bits; + pgt->start_level =kvm_start_level (va_bits); + + pgt->pgd = (kvm_pte_t *)get_zeroed_page (GFP_KERNEL ); +if (!pgt->pgd) { +kfree (pgt); + pgt =NULL ; + } + +return pgt; +} + +static int hyp_free_walker (u64 addr,u64 end,u32 level,kvm_pte_t *ptep, +enum kvm_pgtable_walk_flags flag,void *const arg) +{ +free_page ((unsigned long )kvm_pte_follow (*ptep)); +return 0 ; +} + +void kvm_pgtable_hyp_free_cookie (void *cookie) +{ +size_t pgd_sz; +struct kvm_pgtable *pgt = cookie; +struct kvm_pgtable_walker walker = { + .cb = hyp_free_walker, + .flags =KVM_PGTABLE_WALK_TABLE_POST , + }; + +if (kvm_pgtable_walk (cookie,0 ,BIT (pgt->ia_bits), &walker)) +kvm_err ("Failed to free page-table pages\n" );
Quoted 8 lines
arch/arm64/kvm/pgtable.c int kvm_pgtable_walk(void *cookie, u64 addr, u64 size, · line 437
Quoted 3 lines
arch/arm64/kvm/pgtable.c +3
-0+ + pgd_sz =kvm_pgd_pages (pgt) *PAGE_SIZE ; +free_pages_exact (pgt->pgd, pgd_sz);Given that the pgd is unconditionally a single page for the stage 1 case (as per
kvm_pgtable_hyp_alloc_cookie()above), should we simplify this to a simplefree_page()? Or did you want to factorize this with the stage 2 free path?
Hmm, or maybe it's the alloc() path that needs fixing actually ...
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerRe: [PATCH 02/20] KVM: arm64: Add support for creating kernel-agnostic stage-1 page tables
Quoted 48 lines · Quentin Perret
Quoted 38 lines · Quentin Perret
Quoted 37 lines · Will Deacon
arch/arm64/kvm/pgtable.c +37
-0+void *kvm_pgtable_hyp_alloc_cookie (u32 va_bits) +{ +struct kvm_pgtable *pgt =kzalloc (sizeof (*pgt),GFP_KERNEL ); + +if (!pgt) +return NULL ; + + pgt->ia_bits = va_bits; + pgt->start_level =kvm_start_level (va_bits); + + pgt->pgd = (kvm_pte_t *)get_zeroed_page (GFP_KERNEL ); +if (!pgt->pgd) { +kfree (pgt); + pgt =NULL ; + } + +return pgt; +} + +static int hyp_free_walker (u64 addr,u64 end,u32 level,kvm_pte_t *ptep, +enum kvm_pgtable_walk_flags flag,void *const arg) +{ +free_page ((unsigned long )kvm_pte_follow (*ptep)); +return 0 ; +} + +void kvm_pgtable_hyp_free_cookie (void *cookie) +{ +size_t pgd_sz; +struct kvm_pgtable *pgt = cookie; +struct kvm_pgtable_walker walker = { + .cb = hyp_free_walker, + .flags =KVM_PGTABLE_WALK_TABLE_POST , + }; + +if (kvm_pgtable_walk (cookie,0 ,BIT (pgt->ia_bits), &walker)) +kvm_err ("Failed to free page-table pages\n" );Quoted 8 lines
arch/arm64/kvm/pgtable.c int kvm_pgtable_walk(void *cookie, u64 addr, u64 size, · line 437
Quoted 3 lines
arch/arm64/kvm/pgtable.c +3
-0+ + pgd_sz =kvm_pgd_pages (pgt) *PAGE_SIZE ; +free_pages_exact (pgt->pgd, pgd_sz);Given that the pgd is unconditionally a single page for the stage 1 case (as per
kvm_pgtable_hyp_alloc_cookie()above), should we simplify this to a simplefree_page()? Or did you want to factorize this with the stage 2 free path?
Quoted 1 line
Hmm, or maybe it's the
alloc()path that needs fixing actually ...
No, I think you're right. The hyp stage-1 PGD is always a single page, so I can simplify the free() path. At one point, I had a common free() path for stage-1 and stage-2, but that didn't last very long, as the stage-2 page-table pages are refcounted so you end up having to deal with them differently anyway.
Do you think there is a functional issue here? I don't immediately see it.
Will
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 02/20] KVM: arm64: Add support for creating kernel-agnostic stage-1 page tables
Quoted 2 lines · Will Deacon
No, I think you're right. The hyp stage-1 PGD is always a single page, so I can simplify the
free()path.
OK, cool. The current code does support concatenated pgds for the hyp stage 1, which is what confused me. Would you mind adding something to the commit message explaining why this is no longer needed or something? Or at least mention it here so I understand :) ?
Quoted 4 lines
At one point, I had a common
free()path for
stage-1 and stage-2, but that didn't last very long, as the stage-2 page-table pages are refcounted so you end up having to deal with them differently anyway.
Right, though refcounting the pages for stage 1 might be a good idea too. The current code does it, and I think we'll need it later on for the Protected KVM stuff as unmap() will be needed for stage 1 as well. I'm fine if this is done in a separate series, though. I don't think we need any of that just yet, so we can definitely start 'simple'.
Cheers,
Quentin
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 02/20] KVM: arm64: Add support for creating kernel-agnostic stage-1 page tables
Quoted 8 lines · Quentin Perret
Quoted 2 lines · Will Deacon
No, I think you're right. The hyp stage-1 PGD is always a single page, so I can simplify the
free()path.OK, cool. The current code does support concatenated pgds for the hyp stage 1, which is what confused me. Would you mind adding something to the commit message explaining why this is no longer needed or something? Or at least mention it here so I understand :) ?
Scratch that, this makes no sense. We obviously don't support that, it's just the current code that highly confused me. Sorry fot the noise.
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 3/20 KVM: arm64: Use generic allocator for hyp stage-1 page-tables
In reply to Will DeaconNow that we have a shiny new page-table allocator, replace the hyp page-table code with calls into the new API. This also allows us to remove the extended idmap code, as we can now simply ensure that the VA size is large enough to map everything we need.
--- arch/arm64/include/asm/kvm_mmu.h | 78 +---- arch/arm64/include/asm/kvm_pgtable.h | 5 + arch/arm64/include/asm/pgtable-hwdef.h | 6 - arch/arm64/include/asm/pgtable-prot.h | 6 - arch/arm64/kvm/mmu.c | 410 ++----------------------- 5 files changed, 39 insertions(+), 466 deletions(-)
arch/arm64/include/asm/kvm_mmu.h +2 -76
@@ -43,16 +43,6 @@* HYP_VA_MIN = 1 << (VA_BITS - 1) * HYP_VA_MAX = HYP_VA_MIN + (1 << (VA_BITS - 1)) - 1 * -* This of course assumes that the trampoline page exists within the -* VA_BITS range. If it doesn't, then it means we're in the odd case -* where the kernel idmap (as well as HYP) uses more levels than the -* kernel runtime page tables (as seen when the kernel is configured -* for 4k pages, 39bits VA, and yet memory lives just above that -* limit, forcing the idmap to use 4 levels of page tables while the -* kernel itself only uses 3). In this particular case, it doesn't -* matter which side of VA_BITS we use, as we're guaranteed not to -* conflict with anything. -* * When using VHE, there are no separate hyp mappings and all KVM * functionality is already mapped as part of the main kernel * mappings, and none of this applies in that case.
@@ -123,9 +113,10 @@ static inline bool kvm_page_empty(void *ptr)return page_count (ptr_page) ==1 ; } +#include <asm/kvm_pgtable.h> #include <asm/stage2_pgtable.h> -int create_hyp_mappings (void *from,void *to,pgprot_t prot); +int create_hyp_mappings (void *from,void *to,enum kvm_pgtable_prot prot);int create_hyp_io_mappings (phys_addr_t phys_addr,size_t size,void __iomem **kaddr,void __iomem **haddr);
@@ -146,8 +137,6 @@ void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);phys_addr_t kvm_mmu_get_httbr (void );phys_addr_t kvm_get_idmap_vector (void );int kvm_mmu_init (void ); -void kvm_clear_hyp_idmap (void ); -#define kvm_mk_pmd (ptep) \ __pmd(__phys_to_pmd_val(__pa(ptep)) | PMD_TYPE_TABLE)#define kvm_mk_pud (pmdp) \
@@ -265,25 +254,6 @@ static inline bool kvm_s2pud_young(pud_t pud)return pud_young (pud); } -#define hyp_pte_table_empty (ptep) kvm_page_empty(ptep) - -#ifdef __PAGETABLE_PMD_FOLDED -#define hyp_pmd_table_empty (pmdp) (0) -#else -#define hyp_pmd_table_empty (pmdp) kvm_page_empty(pmdp) -#endif - -#ifdef __PAGETABLE_PUD_FOLDED -#define hyp_pud_table_empty (pudp) (0) -#else -#define hyp_pud_table_empty (pudp) kvm_page_empty(pudp) -#endif - -#ifdef __PAGETABLE_P4D_FOLDED -#define hyp_p4d_table_empty (p4dp) (0) -#else -#define hyp_p4d_table_empty (p4dp) kvm_page_empty(p4dp) -#endif struct kvm ;
@@ -352,50 +322,6 @@ static inline void __kvm_flush_dcache_pud(pud_t pud)void kvm_set_way_flush (struct kvm_vcpu *vcpu);void kvm_toggle_cache (struct kvm_vcpu *vcpu,bool was_enabled); -static inline bool __kvm_cpu_uses_extended_idmap (void ) -{ -return __cpu_uses_extended_idmap_level (); -} - -static inline unsigned long __kvm_idmap_ptrs_per_pgd (void ) -{ -return idmap_ptrs_per_pgd; -} - -/* -* Can't use pgd_populate here, because the extended idmap adds an extra level -* above CONFIG_PGTABLE_LEVELS (which is 2 or 3 if we're using the extended -* idmap), and pgd_populate is only available if CONFIG_PGTABLE_LEVELS = 4. -*/ -static inline void __kvm_extend_hypmap (pgd_t *boot_hyp_pgd, -pgd_t *hyp_pgd, -pgd_t *merged_hyp_pgd, -unsigned long hyp_idmap_start) -{ -int idmap_idx; -u64 pgd_addr; - -/* -* Use the first entry to access the HYP mappings. It is -* guaranteed to be free, otherwise we wouldn't use an -* extended idmap. -*/ -VM_BUG_ON (pgd_val (merged_hyp_pgd[0 ])); - pgd_addr =__phys_to_pgd_val (__pa (hyp_pgd)); - merged_hyp_pgd[0 ] =__pgd (pgd_addr |PMD_TYPE_TABLE ); - -/* -* Create another extended level entry that points to the boot HYP map, -* which contains an ID mapping of the HYP init code. We essentially -* merge the boot and runtime HYP maps by doing so, but they don't -* overlap anyway, so this is fine. -*/ - idmap_idx = hyp_idmap_start >>VA_BITS ; -VM_BUG_ON (pgd_val (merged_hyp_pgd[idmap_idx])); - pgd_addr =__phys_to_pgd_val (__pa (boot_hyp_pgd)); - merged_hyp_pgd[idmap_idx] =__pgd (pgd_addr |PMD_TYPE_TABLE ); -} -static inline unsigned int kvm_get_vmid_bits (void ) {int reg =read_sanitised_ftr_reg (SYS_ID_AA64MMFR1_EL1 );
arch/arm64/include/asm/kvm_pgtable.h +5 -0
@@ -28,6 +28,11 @@ enum kvm_pgtable_prot { KVM_PGTABLE_PROT_DEVICE = BIT(3), }; +#define PAGE_HYP (KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W) +#define PAGE_HYP_EXEC (KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_X) +#define PAGE_HYP_RO (KVM_PGTABLE_PROT_R) +#define PAGE_HYP_DEVICE (PAGE_HYP | KVM_PGTABLE_PROT_DEVICE) +/** * enum kvm_pgtable_walk_flags - Flags to control a depth-first page-table walk. * @KVM_PGTABLE_WALK_LEAF: Visit leaf entries, including invalid
arch/arm64/include/asm/pgtable-hwdef.h +0 -6
@@ -194,12 +194,6 @@*/ #define PTE_S2_MEMATTR (t) (_AT(pteval_t, (t)) << 2) -/* -* EL2/HYP PTE/PMD definitions -*/ -#define PMD_HYP PMD_SECT_USER -#define PTE_HYP PTE_USER -/* * Highest possible physical address supported. */
arch/arm64/include/asm/pgtable-prot.h +0 -6
@@ -56,7 +56,6 @@ extern bool arm64_use_ng_mappings;#define PROT_SECT_NORMAL_EXEC (PROT_SECT_DEFAULT | PMD_SECT_UXN | PMD_ATTRINDX(MT_NORMAL))#define _PAGE_DEFAULT (_PROT_DEFAULT | PTE_ATTRINDX(MT_NORMAL)) -#define _HYP_PAGE_DEFAULT _PAGE_DEFAULT#define PAGE_KERNEL __pgprot(PROT_NORMAL)#define PAGE_KERNEL_RO __pgprot((PROT_NORMAL & ~PTE_WRITE) | PTE_RDONLY)
@@ -64,11 +63,6 @@ extern bool arm64_use_ng_mappings;#define PAGE_KERNEL_EXEC __pgprot(PROT_NORMAL & ~PTE_PXN)#define PAGE_KERNEL_EXEC_CONT __pgprot((PROT_NORMAL & ~PTE_PXN) | PTE_CONT) -#define PAGE_HYP __pgprot(_HYP_PAGE_DEFAULT | PTE_HYP | PTE_HYP_XN) -#define PAGE_HYP_EXEC __pgprot(_HYP_PAGE_DEFAULT | PTE_HYP | PTE_RDONLY) -#define PAGE_HYP_RO __pgprot(_HYP_PAGE_DEFAULT | PTE_HYP | PTE_RDONLY | PTE_HYP_XN) -#define PAGE_HYP_DEVICE __pgprot(PROT_DEVICE_nGnRE | PTE_HYP) -#define PAGE_S2_MEMATTR (attr) \ ({ \ u64 __val; \
arch/arm64/kvm/mmu.c +32 -378
515 lines not on this page · raw message
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 4/20 KVM: arm64: Add support for creating kernel-agnostic stage-2 page tables
In reply to Will DeaconIntroduce alloc() and free() functions to the generic page-table code for guest stage-2 page-tables and plumb these into the existing KVM page-table allocator. Subsequent patches will convert other operations within the KVM allocator over to the generic code.
--- arch/arm64/include/asm/kvm_host.h | 1 + arch/arm64/include/asm/kvm_pgtable.h | 17 ++++++++ arch/arm64/kvm/mmu.c | 42 ++++++++------------ arch/arm64/kvm/pgtable.c | 58 ++++++++++++++++++++++++++++ 4 files changed, 93 insertions(+), 25 deletions(-)
arch/arm64/include/asm/kvm_host.h +1 -0
@@ -81,6 +81,7 @@ struct kvm_s2_mmu {*/ pgd_t *pgd;phys_addr_t pgd_phys; +void *pgt_cookie;/* The last vcpu id that ran on each physical CPU */ int __percpu *last_vcpu_ran;
arch/arm64/include/asm/kvm_pgtable.h +17 -0
@@ -99,6 +99,23 @@ void kvm_pgtable_hyp_free_cookie(void *cookie);int kvm_pgtable_hyp_map (void *cookie,u64 addr,u64 size,u64 phys,enum kvm_pgtable_prot prot); +/** +* kvm_pgtable_stage2_alloc_cookie() - Allocate a guest stage-2 page-table. +* @kvm: KVM structure representing the guest virtual machine. +* +* Return: An opaque cookie which can be used to manipulate the page-table. +*/ +void *kvm_pgtable_stage2_alloc_cookie (struct kvm *kvm); + +/** +* kvm_pgtable_stage2_free_cookie() - Free an unused guest stage-2 page-table. +* @cookie: Opaque cookie allocated by kvm_pgtable_stage2_alloc_cookie(). +* +* The page-table is assumed to be unreachable by any hardware walkers prior +* to freeing and therefore no TLB invalidation is performed. +*/ +void kvm_pgtable_stage2_free_cookie (void *cookie); +/** * kvm_pgtable_get_pgd_phys() - Get physical pgd pointer for a page-table. * @cookie: Opaque cookie allocated by kvm_pgtable_*_alloc_cookie().
arch/arm64/kvm/mmu.c +17 -25
81 lines not on this page · raw message
arch/arm64/kvm/pgtable.c +58 -0
61 lines not on this page · raw message
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 5/20 KVM: arm64: Add support for stage-2 map()/unmap() in generic page-table
In reply to Will DeaconAdd stage-2 map() and unmap() operations to the generic page-table code.
--- arch/arm64/include/asm/kvm_pgtable.h | 39 ++++ arch/arm64/kvm/pgtable.c | 265 +++++++++++++++++++++++++++ 2 files changed, 304 insertions(+)
arch/arm64/include/asm/kvm_pgtable.h +39 -0
@@ -116,6 +116,45 @@ void *kvm_pgtable_stage2_alloc_cookie(struct kvm *kvm);*/ void kvm_pgtable_stage2_free_cookie (void *cookie); +/** +* kvm_pgtable_stage2_map() - Install a mapping in a guest stage-2 page-table. +* @cookie: Opaque cookie allocated by kvm_pgtable_stage2_alloc_cookie(). +* @addr: Intermediate physical address at which to place the mapping. +* @size: Size of the mapping. +* @phys: Physical address of the memory to map. +* @prot: Permissions and attributes for the mapping. +* @mc: Cache of pre-allocated GFP_PGTABLE_USER memory from which to +* allocate page-table pages. +* +* If device attributes are not explicitly requested in @prot, then the +* mapping will be normal, cacheable. +* +* Note that this function will both coalesce existing table entries and split +* existing block mappings, relying on page-faults to fault back areas outside +* of the new mapping lazily. +* +* Return: 0 on success, negative error code on failure. +*/ +int kvm_pgtable_stage2_map (void *cookie,u64 addr,u64 size,u64 phys, +enum kvm_pgtable_prot prot, +struct kvm_mmu_memory_cache *mc); + +/** +* kvm_pgtable_stage2_unmap() - Remove a mapping from a guest stage-2 page-table. +* @cookie: Opaque cookie allocated by kvm_pgtable_stage2_alloc_cookie(). +* @addr: Intermediate physical address from which to remove the mapping. +* @size: Size of the mapping. +* +* TLB invalidation is performed for each page-table entry cleared during the +* unmapping operation and the reference count for the page-table page +* containing the cleared entry is decremented, with unreferenced pages being +* freed. Unmapping a cacheable page will ensure that it is clean to the PoC if +* FWB is not supported by the CPU. +* +* Return: 0 on success, negative error code on failure. +*/ +int kvm_pgtable_stage2_unmap (void *cookie,u64 addr,u64 size); +/** * kvm_pgtable_get_pgd_phys() - Get physical pgd pointer for a page-table. * @cookie: Opaque cookie allocated by kvm_pgtable_*_alloc_cookie().
arch/arm64/kvm/pgtable.c +265 -0
281 lines not on this page · raw message
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 6/20 KVM: arm64: Convert kvm_phys_addr_ioremap() to generic page-table API
In reply to Will DeaconConvert kvm_phys_addr_ioremap() to use kvm_pgtable_stage2_map() instead of stage2_set_pte().
--- arch/arm64/kvm/mmu.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-)
arch/arm64/kvm/mmu.c +10 -14
@@ -1171,31 +1171,27 @@ static int stage2_pudp_test_and_clear_young(pud_t *pud)int kvm_phys_addr_ioremap (struct kvm *kvm,phys_addr_t guest_ipa,phys_addr_t pa,unsigned long size,bool writable) { -phys_addr_t addr, end; +phys_addr_t addr;int ret =0 ; -unsigned long pfn;struct kvm_mmu_memory_cache cache = {0 , }; +void *cookie = kvm->arch.mmu.pgt_cookie; +enum kvm_pgtable_prot prot =KVM_PGTABLE_PROT_DEVICE | +KVM_PGTABLE_PROT_R | + (writable ?KVM_PGTABLE_PROT_W :0 ); - end = (guest_ipa + size +PAGE_SIZE -1 ) &PAGE_MASK ; - pfn =__phys_to_pfn (pa); - -for (addr = guest_ipa; addr < end; addr +=PAGE_SIZE ) { -pte_t pte =kvm_pfn_pte (pfn,PAGE_S2_DEVICE ); - -if (writable) - pte =kvm_s2pte_mkwrite (pte); - +for (addr = guest_ipa; addr < guest_ipa + size; addr +=PAGE_SIZE ) { ret =mmu_topup_memory_cache (kvm, &cache);if (ret)break ; +spin_lock (&kvm->mmu_lock); - ret =stage2_set_pte (&kvm->arch.mmu, &cache, addr, &pte, -KVM_S2PTE_FLAG_IS_IOMAP ); + ret =kvm_pgtable_stage2_map (cookie, addr,PAGE_SIZE , pa, prot, + &cache);spin_unlock (&kvm->mmu_lock);if (ret)break ; - pfn++; + pa +=PAGE_SIZE ; }return ret;
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 7/20 KVM: arm64: Convert kvm_set_spte_hva() to generic page-table API
In reply to Will DeaconConvert kvm_set_spte_hva() to use kvm_pgtable_stage2_map() instead of stage2_set_pte().
--- arch/arm64/kvm/mmu.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-)
arch/arm64/kvm/mmu.c +10 -13
@@ -1924,28 +1924,27 @@ int kvm_unmap_hva_range(struct kvm *kvm,static int kvm_set_spte_handler (struct kvm *kvm,gpa_t gpa,u64 size,void *data) { -pte_t *pte = (pte_t *)data; +kvm_pfn_t *pfn = (kvm_pfn_t *)data;WARN_ON (size !=PAGE_SIZE ); +/* -* We can always call stage2_set_pte with KVM_S2PTE_FLAG_LOGGING_ACTIVE -* flag clear because MMU notifiers will have unmapped a huge PMD before -* calling ->change_pte() (which in turn calls kvm_set_spte_hva()) and -* therefore stage2_set_pte() never needs to clear out a huge PMD -* through this calling path. +* The MMU notifiers will have unmapped a huge PMD before calling +* ->change_pte() (which in turn calls kvm_set_spte_hva()) and +* therefore we never need to clear out a huge PMD through this +* calling path and a memcache is not required. */ -stage2_set_pte (&kvm->arch.mmu,NULL , gpa, pte,0 ); +WARN_ON (kvm_pgtable_stage2_map (kvm, gpa,PAGE_SIZE ,__pfn_to_phys (*pfn), +KVM_PGTABLE_PROT_R ,NULL ));return 0 ; } -int kvm_set_spte_hva (struct kvm *kvm,unsigned long hva,pte_t pte) {unsigned long end = hva +PAGE_SIZE ;kvm_pfn_t pfn =pte_pfn (pte); -pte_t stage2_pte; -if (!kvm->arch.mmu.pgd) +if (!kvm->arch.mmu.pgt_cookie)return 0 ;trace_kvm_set_spte_hva (hva);
@@ -1955,9 +1954,7 @@ int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)* just like a translation fault and clean the cache to the PoC. */ clean_dcache_guest_page (pfn,PAGE_SIZE ); - stage2_pte =kvm_pfn_pte (pfn,PAGE_S2 ); -handle_hva_to_gpa (kvm, hva, end, &kvm_set_spte_handler, &stage2_pte); - +handle_hva_to_gpa (kvm, hva, end, &kvm_set_spte_handler, &pfn);return 0 ; }
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 8/20 KVM: arm64: Convert unmap_stage2_range() to generic page-table API
In reply to Will DeaconConvert unmap_stage2_range() to use kvm_pgtable_stage2_unmap() instead of walking the page-table directly.
--- arch/arm64/kvm/mmu.c | 58 +++++++++++++++++++++++++------------------- 1 file changed, 33 insertions(+), 25 deletions(-)
arch/arm64/kvm/mmu.c +33 -25
@@ -39,6 +39,32 @@ static bool is_iomap(unsigned long flags)return flags &KVM_S2PTE_FLAG_IS_IOMAP ; } +/* +* Release kvm_mmu_lock periodically if the memory region is large. Otherwise, +* we may see kernel panics with CONFIG_DETECT_HUNG_TASK, +* CONFIG_LOCKUP_DETECTOR, CONFIG_LOCKDEP. Additionally, holding the lock too +* long will also starve other vCPUs. We have to also make sure that the page +* tables are not freed while we released the lock. +*/ +#define stage2_apply_range_resched (kvm, addr, end, fn) \ +({ \ + int ret; \ + struct kvm *__kvm = (kvm); \ + u64 next, __addr = (addr), __end = (end); \ + do { \ + void *cookie = __kvm->arch.mmu.pgt_cookie; \ + if (!cookie) \ + break; \ + next = stage2_pgd_addr_end(__kvm, __addr, __end); \ + ret = fn(cookie, __addr, next - __addr); \ + if (ret) \ + break; \ + if (next != __end) \ + cond_resched_lock(&__kvm->mmu_lock); \ + } while (__addr = next, __addr != __end); \ + ret; \ +}) +static bool memslot_is_logging (struct kvm_memory_slot *memslot) {return memslot->dirty_bitmap && !(memslot->flags &KVM_MEM_READONLY );
@@ -256,8 +282,8 @@ static inline void kvm_pgd_populate(pgd_t *pgdp, p4d_t *p4dp)* end up writing old data to disk. * * This is why right after unmapping a page/section and invalidating -* the corresponding TLBs, we call kvm_flush_dcache_p*() to make sure -* the IO subsystem will never hit in the cache. +* the corresponding TLBs, we flush to make sure the IO subsystem will +* never hit in the cache. * * This is all avoided on systems that have ARM64_HAS_STAGE2_FWB, as * we then fully enforce cacheability of RAM, no matter what the guest
@@ -375,36 +401,18 @@ static void unmap_stage2_p4ds(struct kvm_s2_mmu *mmu, pgd_t *pgd,* be called while holding mmu_lock (unless for freeing the stage2 pgd before * destroying the VM), otherwise another faulting VCPU may come in and mess * with things behind our backs. +* +* Return: 0 on success, negative error code on failure. */ static void unmap_stage2_range (struct kvm_s2_mmu *mmu,phys_addr_t start,u64 size) {struct kvm *kvm = mmu->kvm; -pgd_t *pgd; -phys_addr_t addr = start, end = start + size; -phys_addr_t next; +phys_addr_t end = start + size;assert_spin_locked (&kvm->mmu_lock);WARN_ON (size & ~PAGE_MASK ); - - pgd = mmu->pgd +stage2_pgd_index (kvm, addr); -do { -/* -* Make sure the page table is still active, as another thread -* could have possibly freed the page table, while we released -* the lock. -*/ -if (!READ_ONCE (mmu->pgd)) -break ; - next =stage2_pgd_addr_end (kvm, addr, end); -if (!stage2_pgd_none (kvm, *pgd)) -unmap_stage2_p4ds (mmu, pgd, addr, next); -/* -* If the range is too large, release the kvm->mmu_lock -* to prevent starvation and lockup detector warnings. -*/ -if (next != end) -cond_resched_lock (&kvm->mmu_lock); - }while (pgd++, addr = next, addr != end); +WARN_ON (stage2_apply_range_resched (kvm, start, end, + kvm_pgtable_stage2_unmap)); } static void stage2_flush_ptes(struct kvm_s2_mmu *mmu, pmd_t *pmd,
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 9/20 KVM: arm64: Add support for stage-2 page-aging in generic page-table
In reply to Will DeaconAdd stage-2 mkyoung(), mkold() and is_young() operations to the generic page-table code.
--- arch/arm64/include/asm/kvm_pgtable.h | 38 +++++++++++++ arch/arm64/kvm/pgtable.c | 85 ++++++++++++++++++++++++++++ 2 files changed, 123 insertions(+)
arch/arm64/include/asm/kvm_pgtable.h +38 -0
@@ -155,6 +155,44 @@ int kvm_pgtable_stage2_map(void *cookie, u64 addr, u64 size, u64 phys,*/ int kvm_pgtable_stage2_unmap (void *cookie,u64 addr,u64 size); +/** +* kvm_pgtable_stage2_mkyoung() - Set the access flag in a page-table entry. +* @cookie: Opaque cookie allocated by kvm_pgtable_stage2_alloc_cookie(). +* @addr: Intermediate physical address to identify the page-table entry. +* +* If there is a valid, leaf page-table entry used to translate @addr, then +* set the access flag in that entry. +* +* Return: The old page-table entry prior to setting the flag, 0 on failure. +*/ +kvm_pte_t kvm_pgtable_stage2_mkyoung (void *cookie,u64 addr); + +/** +* kvm_pgtable_stage2_mkold() - Clear the access flag in a page-table entry. +* @cookie: Opaque cookie allocated by kvm_pgtable_stage2_alloc_cookie(). +* @addr: Intermediate physical address to identify the page-table entry. +* +* If there is a valid, leaf page-table entry used to translate @addr, then +* clear the access flag in that entry. +* +* Note that it is the caller's responsibility to invalidate the TLB after +* calling this function to ensure that the updated permissions are visible +* to the CPUs. +* +* Return: The old page-table entry prior to clearing the flag, 0 on failure. +*/ +kvm_pte_t kvm_pgtable_stage2_mkold (void *cookie,u64 addr); + +/** +* kvm_pgtable_stage2_is_young() - Test whether a page-table entry has the +* access flag set. +* @cookie: Opaque cookie allocated by kvm_pgtable_stage2_alloc_cookie(). +* @addr: Intermediate physical address to identify the page-table entry. +* +* Return: True if the page-table entry has the access flag set, false otherwise. +*/ +bool kvm_pgtable_stage2_is_young (void *cookie,u64 addr); +/** * kvm_pgtable_get_pgd_phys() - Get physical pgd pointer for a page-table. * @cookie: Opaque cookie allocated by kvm_pgtable_*_alloc_cookie().
arch/arm64/kvm/pgtable.c +85 -0
91 lines not on this page · raw message
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 10/20 KVM: arm64: Convert page-aging and access faults to generic page-table API
In reply to Will DeaconConvert the page-aging functions and access fault handler to use the generic page-table code instead of walking the page-table directly.
--- arch/arm64/kvm/mmu.c | 74 ++++++++++---------------------------------- 1 file changed, 16 insertions(+), 58 deletions(-)
arch/arm64/kvm/mmu.c +16 -58
@@ -1714,46 +1714,23 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,return ret; } -/* -* Resolve the access fault by making the page young again. -* Note that because the faulting entry is guaranteed not to be -* cached in the TLB, we don't need to invalidate anything. -* Only the HW Access Flag updates are supported for Stage 2 (no DBM), -* so there is no need for atomic (pte|pmd)_mkyoung operations. -*/ +/* Resolve the access fault by making the page young again. */ static void handle_access_fault (struct kvm_vcpu *vcpu,phys_addr_t fault_ipa) { -pud_t *pud; -pmd_t *pmd; -pte_t *pte; -kvm_pfn_t pfn; -bool pfn_valid = false; +pte_t pte; +kvm_pte_t kpte; +struct kvm_s2_mmu *mmu;trace_kvm_access_fault (fault_ipa);spin_lock (&vcpu->kvm->mmu_lock); - -if (!stage2_get_leaf_entry (vcpu->arch.hw_mmu, fault_ipa, &pud, &pmd, &pte)) - goto out; - -if (pud) {/* HugeTLB */ - *pud =kvm_s2pud_mkyoung (*pud); - pfn =kvm_pud_pfn (*pud); - pfn_valid = true; - }else if (pmd) {/* THP, HugeTLB */ - *pmd =pmd_mkyoung (*pmd); - pfn =pmd_pfn (*pmd); - pfn_valid = true; - }else { - *pte =pte_mkyoung (*pte);/* Just a page... */ - pfn =pte_pfn (*pte); - pfn_valid = true; - } - -out: + mmu = vcpu->arch.hw_mmu; + kpte =kvm_pgtable_stage2_mkyoung (mmu->pgt_cookie, fault_ipa);spin_unlock (&vcpu->kvm->mmu_lock); -if (pfn_valid) -kvm_set_pfn_accessed (pfn); + + pte =__pte (kpte); +if (pte_valid (pte)) +kvm_set_pfn_accessed (pte_pfn (pte)); }/**
@@ -1968,38 +1945,19 @@ int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)static int kvm_age_hva_handler (struct kvm *kvm,gpa_t gpa,u64 size,void *data) { -pud_t *pud; -pmd_t *pmd; -pte_t *pte; +pte_t pte; +kvm_pte_t kpte;WARN_ON (size !=PAGE_SIZE && size !=PMD_SIZE && size !=PUD_SIZE ); -if (!stage2_get_leaf_entry (&kvm->arch.mmu, gpa, &pud, &pmd, &pte)) -return 0 ; - -if (pud) -return stage2_pudp_test_and_clear_young (pud); -else if (pmd) -return stage2_pmdp_test_and_clear_young (pmd); -else -return stage2_ptep_test_and_clear_young (pte); + kpte =kvm_pgtable_stage2_mkold (kvm->arch.mmu.pgt_cookie, gpa); + pte =__pte (kpte); +return pte_valid (pte) &&pte_young (pte); }static int kvm_test_age_hva_handler (struct kvm *kvm,gpa_t gpa,u64 size,void *data) { -pud_t *pud; -pmd_t *pmd; -pte_t *pte; -WARN_ON (size !=PAGE_SIZE && size !=PMD_SIZE && size !=PUD_SIZE ); -if (!stage2_get_leaf_entry (&kvm->arch.mmu, gpa, &pud, &pmd, &pte)) -return 0 ; - -if (pud) -return kvm_s2pud_young (*pud); -else if (pmd) -return pmd_young (*pmd); -else -return pte_young (*pte); +return kvm_pgtable_stage2_is_young (kvm->arch.mmu.pgt_cookie, gpa); }int kvm_age_hva (struct kvm *kvm,unsigned long start,unsigned long end)
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 11/20 KVM: arm64: Add support for stage-2 write-protect in generic page-table
In reply to Will DeaconFrom: Quentin Perret <[email protected]>
Add a stage-2 wrprotect() operation to the generic page-table code.
--- arch/arm64/include/asm/kvm_pgtable.h | 15 +++++++++++++++ arch/arm64/kvm/pgtable.c | 6 ++++++ 2 files changed, 21 insertions(+)
arch/arm64/include/asm/kvm_pgtable.h +15 -0
@@ -155,6 +155,21 @@ int kvm_pgtable_stage2_map(void *cookie, u64 addr, u64 size, u64 phys,*/ int kvm_pgtable_stage2_unmap (void *cookie,u64 addr,u64 size); +/** +* kvm_pgtable_stage2_wrprotect() - Write-protect guest stage-2 address range +* without TLB invalidation. +* @cookie: Opaque cookie allocated by kvm_pgtable_stage2_alloc_cookie(). +* @addr: Intermediate physical address from which to write-protect, +* @size: Size of the range. +* +* Note that it is the caller's responsibility to invalidate the TLB after +* calling this function to ensure that the updated permissions are visible +* to the CPUs. +* +* Return: 0 on success, negative error code on failure. +*/ +int kvm_pgtable_stage2_wrprotect (void *cookie,u64 addr,u64 size); +/** * kvm_pgtable_stage2_mkyoung() - Set the access flag in a page-table entry. * @cookie: Opaque cookie allocated by kvm_pgtable_stage2_alloc_cookie().
arch/arm64/kvm/pgtable.c +6 -0
@@ -764,6 +764,12 @@ static int stage2_update_leaf_attrs(struct kvm_pgtable *pgt, u64 addr,return 0 ; } +int kvm_pgtable_stage2_wrprotect (void *cookie,u64 addr,u64 size) +{ +return stage2_update_leaf_attrs (cookie, addr, size,0 , +KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W ,NULL ); +} +kvm_pte_t kvm_pgtable_stage2_mkyoung (void *cookie,u64 addr) {kvm_pte_t pte =0 ;
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 12/20 KVM: arm64: Convert write-protect operation to generic page-table API
In reply to Will DeaconFrom: Quentin Perret <[email protected]>
Convert stage2_wp_range() to call the kvm_pgtable_stage2_wrprotect() function of the generic page-table code instead of walking the page-table directly.
--- arch/arm64/kvm/mmu.c | 22 +--------------------- 1 file changed, 1 insertion(+), 21 deletions(-)
arch/arm64/kvm/mmu.c +1 -21
@@ -1310,27 +1310,7 @@ static void stage2_wp_p4ds(struct kvm_s2_mmu *mmu, pgd_t *pgd,static void stage2_wp_range (struct kvm_s2_mmu *mmu,phys_addr_t addr,phys_addr_t end) {struct kvm *kvm = mmu->kvm; -pgd_t *pgd; -phys_addr_t next; - - pgd = mmu->pgd +stage2_pgd_index (kvm, addr); -do { -/* -* Release kvm_mmu_lock periodically if the memory region is -* large. Otherwise, we may see kernel panics with -* CONFIG_DETECT_HUNG_TASK, CONFIG_LOCKUP_DETECTOR, -* CONFIG_LOCKDEP. Additionally, holding the lock too long -* will also starve other vCPUs. We have to also make sure -* that the page tables are not freed while we released -* the lock. -*/ -cond_resched_lock (&kvm->mmu_lock); -if (!READ_ONCE (mmu->pgd)) -break ; - next =stage2_pgd_addr_end (kvm, addr, end); -if (stage2_pgd_present (kvm, *pgd)) -stage2_wp_p4ds (mmu, pgd, addr, next); - }while (pgd++, addr = next, addr != end); +stage2_apply_range_resched (kvm, addr, end, kvm_pgtable_stage2_wrprotect); }/**
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 13/20 KVM: arm64: Add support for stage-2 cache flushing in generic page-table
In reply to Will DeaconFrom: Quentin Perret <[email protected]>
Add support for cache flushing a range of the stage-2 address space to the generic page-table code.
--- arch/arm64/include/asm/kvm_pgtable.h | 12 ++++++++++++ arch/arm64/kvm/pgtable.c | 27 +++++++++++++++++++++++++++ 2 files changed, 39 insertions(+)
arch/arm64/include/asm/kvm_pgtable.h +12 -0
@@ -208,6 +208,18 @@ kvm_pte_t kvm_pgtable_stage2_mkold(void *cookie, u64 addr);*/ bool kvm_pgtable_stage2_is_young (void *cookie,u64 addr); +/** +* kvm_pgtable_stage2_flush_range() - Clean and invalidate data cache to Point +* of Coherency for guest stage-2 address +* range. +* @cookie: Opaque cookie allocated by kvm_pgtable_stage2_alloc_cookie(). +* @addr: Intermediate physical address from which to flush. +* @size: Size of the range. +* +* Return: 0 on success, negative error code on failure. +*/ +int kvm_pgtable_stage2_flush (void *cookie,u64 addr,u64 size); +/** * kvm_pgtable_get_pgd_phys() - Get physical pgd pointer for a page-table. * @cookie: Opaque cookie allocated by kvm_pgtable_*_alloc_cookie().
arch/arm64/kvm/pgtable.c +27 -0
@@ -800,6 +800,33 @@ bool kvm_pgtable_stage2_is_young(void *cookie, u64 addr)return !!(pte &KVM_PTE_LEAF_ATTR_LO_S2_AF ); } + +static int stage2_flush_walker (u64 addr,u64 end,u32 level,kvm_pte_t *ptep, +enum kvm_pgtable_walk_flags flag, +void *const arg) +{ +kvm_pte_t pte = *ptep; + +if (!kvm_pte_valid (pte) || !stage2_pte_cacheable (pte)) +return 0 ; + +stage2_flush_dcache (kvm_pte_follow (pte),kvm_granule_size (level)); +return 0 ; +} + +int kvm_pgtable_stage2_flush (void *cookie,u64 addr,u64 size) +{ +struct kvm_pgtable_walker walker = { + .cb = stage2_flush_walker, + .flags =KVM_PGTABLE_WALK_LEAF , + }; + +if (cpus_have_const_cap (ARM64_HAS_STAGE2_FWB )) +return 0 ; + +return kvm_pgtable_walk (cookie, addr, size, &walker); +} +void *kvm_pgtable_stage2_alloc_cookie (struct kvm *kvm) {size_t pgd_sz;
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 14/20 KVM: arm64: Convert memslot cache-flushing code to generic page-table API
In reply to Will DeaconFrom: Quentin Perret <[email protected]>
Convert stage2_flush_memslot() to call the kvm_pgtable_stage2_flush() function of the generic page-table code instead of walking the page-table directly.
--- arch/arm64/kvm/mmu.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-)
arch/arm64/kvm/mmu.c +1 -12
@@ -483,21 +483,10 @@ static void stage2_flush_p4ds(struct kvm_s2_mmu *mmu, pgd_t *pgd,static void stage2_flush_memslot (struct kvm *kvm,struct kvm_memory_slot *memslot) { -struct kvm_s2_mmu *mmu = &kvm->arch.mmu;phys_addr_t addr = memslot->base_gfn <<PAGE_SHIFT ;phys_addr_t end = addr +PAGE_SIZE * memslot->npages; -phys_addr_t next; -pgd_t *pgd; - - pgd = mmu->pgd +stage2_pgd_index (kvm, addr); -do { - next =stage2_pgd_addr_end (kvm, addr, end); -if (!stage2_pgd_none (kvm, *pgd)) -stage2_flush_p4ds (mmu, pgd, addr, next); -if (next != end) -cond_resched_lock (&kvm->mmu_lock); - }while (pgd++, addr = next, addr != end); +stage2_apply_range_resched (kvm, addr, end, kvm_pgtable_stage2_flush); }/**
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 15/20 KVM: arm64: Add support for relaxing stage-2 perms in generic page-table code
In reply to Will DeaconAdd support for relaxing the permissions of a stage-2 mapping (i.e. adding additional permissions) to the generic page-table code.
--- arch/arm64/include/asm/kvm_pgtable.h | 17 +++++++++++++++++ arch/arm64/kvm/pgtable.c | 20 ++++++++++++++++++++ 2 files changed, 37 insertions(+)
arch/arm64/include/asm/kvm_pgtable.h +17 -0
@@ -198,6 +198,23 @@ kvm_pte_t kvm_pgtable_stage2_mkyoung(void *cookie, u64 addr);*/ kvm_pte_t kvm_pgtable_stage2_mkold (void *cookie,u64 addr); +/** +* kvm_pgtable_stage2_relax_perms() - Relax the permissions enforced by a +* page-table entry. +* @cookie: Opaque cookie allocated by kvm_pgtable_stage2_alloc_cookie(). +* @addr: Intermediate physical address to identify the page-table entry. +* @prot: Additional permissions to grant for the mapping. +* +* If there is a valid, leaf page-table entry used to translate @addr, then +* relax the permissions in that entry according to the read, write and +* execute permissions specified by @prot. No permissions are removed, and +* TLB invalidation is performed after updating the entry. +* +* Return: 0 on success, negative error code on failure. +*/ +int kvm_pgtable_stage2_relax_perms (void *cookie,u64 addr, +enum kvm_pgtable_prot prot); +/** * kvm_pgtable_stage2_is_young() - Test whether a page-table entry has the * access flag set.
arch/arm64/kvm/pgtable.c +20 -0
@@ -800,6 +800,26 @@ bool kvm_pgtable_stage2_is_young(void *cookie, u64 addr)return !!(pte &KVM_PTE_LEAF_ATTR_LO_S2_AF ); } +int kvm_pgtable_stage2_relax_perms (void *cookie,u64 addr, +enum kvm_pgtable_prot prot) +{ +int ret; +struct kvm_pgtable *pgt = cookie; +kvm_pte_t set =0 , clr =0 ; + +if (prot &KVM_PGTABLE_PROT_R ) + set |=KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R ; + +if (prot &KVM_PGTABLE_PROT_W ) + set |=KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W ; + +if (prot &KVM_PGTABLE_PROT_X ) + clr |=KVM_PTE_LEAF_ATTR_HI_S2_XN ; + + ret =stage2_update_leaf_attrs (cookie, addr,1 , set, clr,NULL ); +kvm_call_hyp (__kvm_tlb_flush_vmid_ipa, pgt->mmu, addr,0 ); +return ret; +} static int stage2_flush_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep, enum kvm_pgtable_walk_flags flag,
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 16/20 KVM: arm64: Convert user_mem_abort() to generic page-table API
In reply to Will DeaconConvert user_mem_abort() to call kvm_pgtable_stage2_relax_perms() when handling a stage-2 permission fault and kvm_pgtable_stage2_map() when handling a stage-2 translation fault, rather than walking the page-table manually.
--- arch/arm64/kvm/mmu.c | 111 +++++++++++++------------------------------ 1 file changed, 33 insertions(+), 78 deletions(-)
arch/arm64/kvm/mmu.c +33 -78
@@ -1504,7 +1504,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, {int ret;bool write_fault, writable, force_pte = false; -bool exec_fault, needs_exec; +bool exec_fault; +bool device = false;unsigned long mmu_seq;gfn_t gfn = fault_ipa >>PAGE_SHIFT ;struct kvm *kvm = vcpu->kvm;
@@ -1512,10 +1513,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,struct vm_area_struct *vma;short vma_shift;kvm_pfn_t pfn; -pgprot_t mem_type =PAGE_S2 ;bool logging_active =memslot_is_logging (memslot); -unsigned long vma_pagesize, flags =0 ; -struct kvm_s2_mmu *mmu = vcpu->arch.hw_mmu; +unsigned long vma_pagesize; +enum kvm_pgtable_prot prot =KVM_PGTABLE_PROT_R ; +void *cookie; write_fault =kvm_is_write_fault (vcpu); exec_fault =kvm_vcpu_trap_is_iabt (vcpu);
@@ -1548,22 +1549,15 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, vma_pagesize =PAGE_SIZE ; } -/* -* The stage2 has a minimum of 2 level table (For arm64 see -* kvm_arm_setup_stage2()). Hence, we are guaranteed that we can -* use PMD_SIZE huge mappings (even when the PMD is folded into PGD). -* As for PUD huge maps, we must make sure that we have at least -* 3 levels, i.e, PMD is not folded. -*/ -if (vma_pagesize ==PMD_SIZE || - (vma_pagesize ==PUD_SIZE &&kvm_stage2_has_pmd (kvm))) +if (vma_pagesize ==PMD_SIZE || vma_pagesize ==PUD_SIZE ) gfn = (fault_ipa &huge_page_mask (hstate_vma (vma))) >>PAGE_SHIFT ;mmap_read_unlock (current->mm); -/* We need minimum second+third level pages */ - ret =mmu_topup_memory_cache (kvm, memcache); -if (ret) -return ret; +if (fault_status !=FSC_PERM ) { + ret =mmu_topup_memory_cache (kvm, memcache); +if (ret) +return ret; + } mmu_seq = vcpu->kvm->mmu_notifier_seq;/*
@@ -1586,28 +1580,20 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,return -EFAULT ;if (kvm_is_device_pfn (pfn)) { - mem_type =PAGE_S2_DEVICE ; - flags |=KVM_S2PTE_FLAG_IS_IOMAP ; - }else if (logging_active) { -/* -* Faults on pages in a memslot with logging enabled -* should not be mapped with huge pages (it introduces churn -* and performance degradation), so force a pte mapping. -*/ - flags |=KVM_S2_FLAG_LOGGING_ACTIVE ; - + device = true; + }else if (logging_active && !write_fault) {/* * Only actually map the page as writable if this was a write * fault. */ -if (!write_fault) - writable = false; + writable = false; } -if (exec_fault &&is_iomap (flags)) +if (exec_fault && device)return -ENOEXEC ;spin_lock (&kvm->mmu_lock); + cookie = vcpu->arch.hw_mmu->pgt_cookie;if (mmu_notifier_retry (kvm, mmu_seq)) goto out_unlock;
@@ -1618,62 +1604,31 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,if (vma_pagesize ==PAGE_SIZE && !force_pte) vma_pagesize =transparent_hugepage_adjust (memslot, hva, &pfn, &fault_ipa); -if (writable) +if (writable) { + prot |=KVM_PGTABLE_PROT_W ;kvm_set_pfn_dirty (pfn); +mark_page_dirty (kvm, gfn); + } -if (fault_status !=FSC_PERM && !is_iomap (flags)) +if (fault_status !=FSC_PERM && !device)clean_dcache_guest_page (pfn, vma_pagesize); -if (exec_fault) +if (exec_fault) { + prot |=KVM_PGTABLE_PROT_X ;invalidate_icache_guest_page (pfn, vma_pagesize); + } -/* -* If we took an execution fault we have made the -* icache/dcache coherent above and should now let the s2 -* mapping be executable. -* -* Write faults (!exec_fault && FSC_PERM) are orthogonal to -* execute permissions, and we preserve whatever we have. -*/ - needs_exec = exec_fault || - (fault_status ==FSC_PERM && -stage2_is_exec (mmu, fault_ipa, vma_pagesize)); - -if (vma_pagesize ==PUD_SIZE ) { -pud_t new_pud =kvm_pfn_pud (pfn, mem_type); - - new_pud =kvm_pud_mkhuge (new_pud); -if (writable) - new_pud =kvm_s2pud_mkwrite (new_pud); - -if (needs_exec) - new_pud =kvm_s2pud_mkexec (new_pud); - - ret =stage2_set_pud_huge (mmu, memcache, fault_ipa, &new_pud); - }else if (vma_pagesize ==PMD_SIZE ) { -pmd_t new_pmd =kvm_pfn_pmd (pfn, mem_type); - - new_pmd =kvm_pmd_mkhuge (new_pmd); - -if (writable) - new_pmd =kvm_s2pmd_mkwrite (new_pmd); - -if (needs_exec) - new_pmd =kvm_s2pmd_mkexec (new_pmd); +if (device) + prot |=KVM_PGTABLE_PROT_DEVICE ; +else if (cpus_have_const_cap (ARM64_HAS_CACHE_DIC )) + prot |=KVM_PGTABLE_PROT_X ; - ret =stage2_set_pmd_huge (mmu, memcache, fault_ipa, &new_pmd); +if (fault_status ==FSC_PERM ) { + ret =kvm_pgtable_stage2_relax_perms (cookie, fault_ipa, prot); }else { -pte_t new_pte =kvm_pfn_pte (pfn, mem_type); - -if (writable) { - new_pte =kvm_s2pte_mkwrite (new_pte); -mark_page_dirty (kvm, gfn); - } - -if (needs_exec) - new_pte =kvm_s2pte_mkexec (new_pte); - - ret =stage2_set_pte (mmu, memcache, fault_ipa, &new_pte, flags); + ret =kvm_pgtable_stage2_map (cookie, fault_ipa, vma_pagesize, +__pfn_to_phys (pfn), prot, + memcache); } out_unlock:
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 17/20 KVM: arm64: Check the cookie instead of the pgd when modifying page-table
In reply to Will DeaconIn preparation for removing the 'pgd' field of 'struct kvm_s2_mmu', update the few remaining users to check the 'pgt_cookie' field instead.
--- arch/arm64/kvm/mmu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm64/kvm/mmu.c +3 -3
@@ -1823,7 +1823,7 @@ static int kvm_unmap_hva_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *datint kvm_unmap_hva_range (struct kvm *kvm,unsigned long start,unsigned long end) { -if (!kvm->arch.mmu.pgd) +if (!kvm->arch.mmu.pgt_cookie)return 0 ;trace_kvm_unmap_hva_range (start, end);
@@ -1886,7 +1886,7 @@ static int kvm_test_age_hva_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *int kvm_age_hva (struct kvm *kvm,unsigned long start,unsigned long end) { -if (!kvm->arch.mmu.pgd) +if (!kvm->arch.mmu.pgt_cookie)return 0 ;trace_kvm_age_hva (start, end);return handle_hva_to_gpa (kvm, start, end, kvm_age_hva_handler,NULL );
@@ -1894,7 +1894,7 @@ int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end)int kvm_test_age_hva (struct kvm *kvm,unsigned long hva) { -if (!kvm->arch.mmu.pgd) +if (!kvm->arch.mmu.pgt_cookie)return 0 ;trace_kvm_test_age_hva (hva); return handle_hva_to_gpa(kvm, hva, hva + PAGE_SIZE,
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 18/20 KVM: arm64: Remove unused page-table code
In reply to Will DeaconNow that KVM is using the generic page-table code to manage the guest stage-2 page-tables, we can remove a bunch of unused macros, #defines and static inline functions from the old implementation.
--- arch/arm64/include/asm/kvm_mmu.h | 141 ----- arch/arm64/include/asm/pgtable-hwdef.h | 17 - arch/arm64/include/asm/pgtable-prot.h | 13 - arch/arm64/include/asm/stage2_pgtable.h | 215 ------- arch/arm64/kvm/mmu.c | 764 ------------------------ 5 files changed, 1150 deletions(-)
arch/arm64/include/asm/kvm_mmu.h +0 -141
@@ -137,123 +137,6 @@ void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);phys_addr_t kvm_mmu_get_httbr (void );phys_addr_t kvm_get_idmap_vector (void );int kvm_mmu_init (void ); -#define kvm_mk_pmd (ptep) \ - __pmd(__phys_to_pmd_val(__pa(ptep)) | PMD_TYPE_TABLE) -#define kvm_mk_pud (pmdp) \ - __pud(__phys_to_pud_val(__pa(pmdp)) | PMD_TYPE_TABLE) -#define kvm_mk_p4d (pmdp) \ - __p4d(__phys_to_p4d_val(__pa(pmdp)) | PUD_TYPE_TABLE) - -#define kvm_set_pud (pudp, pud) set_pud(pudp, pud) - -#define kvm_pfn_pte (pfn, prot) pfn_pte(pfn, prot) -#define kvm_pfn_pmd (pfn, prot) pfn_pmd(pfn, prot) -#define kvm_pfn_pud (pfn, prot) pfn_pud(pfn, prot) - -#define kvm_pud_pfn (pud) pud_pfn(pud) - -#define kvm_pmd_mkhuge (pmd) pmd_mkhuge(pmd) -#define kvm_pud_mkhuge (pud) pud_mkhuge(pud) - -static inline pte_t kvm_s2pte_mkwrite (pte_t pte) -{ -pte_val (pte) |=PTE_S2_RDWR ; -return pte; -} - -static inline pmd_t kvm_s2pmd_mkwrite (pmd_t pmd) -{ -pmd_val (pmd) |=PMD_S2_RDWR ; -return pmd; -} - -static inline pud_t kvm_s2pud_mkwrite (pud_t pud) -{ -pud_val (pud) |=PUD_S2_RDWR ; -return pud; -} - -static inline pte_t kvm_s2pte_mkexec (pte_t pte) -{ -pte_val (pte) &= ~PTE_S2_XN ; -return pte; -} - -static inline pmd_t kvm_s2pmd_mkexec (pmd_t pmd) -{ -pmd_val (pmd) &= ~PMD_S2_XN ; -return pmd; -} - -static inline pud_t kvm_s2pud_mkexec (pud_t pud) -{ -pud_val (pud) &= ~PUD_S2_XN ; -return pud; -} - -static inline void kvm_set_s2pte_readonly (pte_t *ptep) -{ -pteval_t old_pteval, pteval; - - pteval =READ_ONCE (pte_val (*ptep)); -do { - old_pteval = pteval; - pteval &= ~PTE_S2_RDWR ; - pteval |=PTE_S2_RDONLY ; - pteval =cmpxchg_relaxed (&pte_val (*ptep), old_pteval, pteval); - }while (pteval != old_pteval); -} - -static inline bool kvm_s2pte_readonly (pte_t *ptep) -{ -return (READ_ONCE (pte_val (*ptep)) &PTE_S2_RDWR ) ==PTE_S2_RDONLY ; -} - -static inline bool kvm_s2pte_exec (pte_t *ptep) -{ -return !(READ_ONCE (pte_val (*ptep)) &PTE_S2_XN ); -} - -static inline void kvm_set_s2pmd_readonly (pmd_t *pmdp) -{ -kvm_set_s2pte_readonly ((pte_t *)pmdp); -} - -static inline bool kvm_s2pmd_readonly (pmd_t *pmdp) -{ -return kvm_s2pte_readonly ((pte_t *)pmdp); -} - -static inline bool kvm_s2pmd_exec (pmd_t *pmdp) -{ -return !(READ_ONCE (pmd_val (*pmdp)) &PMD_S2_XN ); -} - -static inline void kvm_set_s2pud_readonly (pud_t *pudp) -{ -kvm_set_s2pte_readonly ((pte_t *)pudp); -} - -static inline bool kvm_s2pud_readonly (pud_t *pudp) -{ -return kvm_s2pte_readonly ((pte_t *)pudp); -} - -static inline bool kvm_s2pud_exec (pud_t *pudp) -{ -return !(READ_ONCE (pud_val (*pudp)) &PUD_S2_XN ); -} - -static inline pud_t kvm_s2pud_mkyoung (pud_t pud) -{ -return pud_mkyoung (pud); -} - -static inline bool kvm_s2pud_young (pud_t pud) -{ -return pud_young (pud); -} -struct kvm ;
@@ -295,30 +178,6 @@ static inline void __invalidate_icache_guest_page(kvm_pfn_t pfn, } } -static inline void __kvm_flush_dcache_pte (pte_t pte) -{ -if (!cpus_have_const_cap (ARM64_HAS_STAGE2_FWB )) { -struct page *page =pte_page (pte); -kvm_flush_dcache_to_poc (page_address (page),PAGE_SIZE ); - } -} - -static inline void __kvm_flush_dcache_pmd (pmd_t pmd) -{ -if (!cpus_have_const_cap (ARM64_HAS_STAGE2_FWB )) { -struct page *page =pmd_page (pmd); -kvm_flush_dcache_to_poc (page_address (page),PMD_SIZE ); - } -} - -static inline void __kvm_flush_dcache_pud (pud_t pud) -{ -if (!cpus_have_const_cap (ARM64_HAS_STAGE2_FWB )) { -struct page *page =pud_page (pud); -kvm_flush_dcache_to_poc (page_address (page),PUD_SIZE ); - } -} -void kvm_set_way_flush (struct kvm_vcpu *vcpu);void kvm_toggle_cache (struct kvm_vcpu *vcpu,bool was_enabled);
arch/arm64/include/asm/pgtable-hwdef.h +0 -17
@@ -172,23 +172,6 @@#define PTE_ATTRINDX (t) (_AT(pteval_t, (t)) << 2)#define PTE_ATTRINDX_MASK (_AT(pteval_t, 7) << 2) -/* -* 2nd stage PTE definitions -*/ -#define PTE_S2_RDONLY (_AT(pteval_t, 1) << 6)/* HAP[2:1] */ -#define PTE_S2_RDWR (_AT(pteval_t, 3) << 6)/* HAP[2:1] */ -#define PTE_S2_XN (_AT(pteval_t, 2) << 53)/* XN[1:0] */ -#define PTE_S2_SW_RESVD (_AT(pteval_t, 15) << 55)/* Reserved for SW */ - -#define PMD_S2_RDONLY (_AT(pmdval_t, 1) << 6)/* HAP[2:1] */ -#define PMD_S2_RDWR (_AT(pmdval_t, 3) << 6)/* HAP[2:1] */ -#define PMD_S2_XN (_AT(pmdval_t, 2) << 53)/* XN[1:0] */ -#define PMD_S2_SW_RESVD (_AT(pmdval_t, 15) << 55)/* Reserved for SW */ - -#define PUD_S2_RDONLY (_AT(pudval_t, 1) << 6)/* HAP[2:1] */ -#define PUD_S2_RDWR (_AT(pudval_t, 3) << 6)/* HAP[2:1] */ -#define PUD_S2_XN (_AT(pudval_t, 2) << 53)/* XN[1:0] */ -/* * Memory Attribute override for Stage-2 (MemAttr[3:0]) */
arch/arm64/include/asm/pgtable-prot.h +0 -13
@@ -73,19 +73,6 @@ extern bool arm64_use_ng_mappings; __val; \ }) -#define PAGE_S2_XN \ - ({ \ - u64 __val; \ - if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC)) \ - __val = 0; \ - else \ - __val = PTE_S2_XN; \ - __val; \ - }) - -#define PAGE_S2 __pgprot(_PROT_DEFAULT | PAGE_S2_MEMATTR(NORMAL) | PTE_S2_RDONLY | PAGE_S2_XN) -#define PAGE_S2_DEVICE __pgprot(_PROT_DEFAULT | PAGE_S2_MEMATTR(DEVICE_nGnRE) | PTE_S2_RDONLY | PTE_S2_XN) -#define PAGE_NONE __pgprot(((_PAGE_DEFAULT) & ~PTE_VALID) | PTE_PROT_NONE | PTE_RDONLY | PTE_NG | PTE_PXN | PTE_UXN)/* shared+writable pages are clean by default, hence PTE_RDONLY|PTE_WRITE */ #define PAGE_SHARED __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_RDONLY | PTE_NG | PTE_PXN | PTE_UXN | PTE_WRITE)
arch/arm64/include/asm/stage2_pgtable.h +0 -215
237 lines not on this page · raw message
arch/arm64/kvm/mmu.c +0 -764
811 lines not on this page · raw message
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 19/20 KVM: arm64: Remove unused 'pgd' field from 'struct kvm_s2_mmu'
In reply to Will DeaconThe stage-2 page-tables are entirely encapsulated by the 'pgt_cookie' field of 'struct kvm_s2_mmu', so remove the unused 'pgd' field.
--- arch/arm64/include/asm/kvm_host.h | 1 - arch/arm64/kvm/mmu.c | 2 -- 2 files changed, 3 deletions(-)
arch/arm64/include/asm/kvm_host.h +0 -1
@@ -79,7 +79,6 @@ struct kvm_s2_mmu {* for vEL1/EL0 with vHCR_EL2.VM == 0. In that case, we use the * canonical stage-2 page tables. */ -pgd_t *pgd;phys_addr_t pgd_phys;void *pgt_cookie;
arch/arm64/kvm/mmu.c +0 -2
@@ -397,7 +397,6 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu) mmu->kvm = kvm; mmu->pgt_cookie = cookie; mmu->pgd_phys =kvm_pgtable_get_pgd_phys (cookie); - mmu->pgd =__va (mmu->pgd_phys); mmu->vmid.vmid_gen =0 ;return 0 ;
@@ -478,7 +477,6 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)spin_lock (&kvm->mmu_lock); cookie = mmu->pgt_cookie;if (cookie) { - mmu->pgd =NULL ; mmu->pgd_phys =0 ; mmu->pgt_cookie =NULL ;free_percpu (mmu->last_vcpu_ran);
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerPATCH 20/20 KVM: arm64: Don't constrain maximum IPA size based on host configuration
In reply to Will DeaconNow that the guest stage-2 page-tables are managed independently from the host stage-1 page-tables, we can avoid constraining the IPA size based on the host and instead limit it only based on the PARange field of the ID_AA64MMFR0 register.
--- arch/arm64/kvm/reset.c | 38 +++++--------------------------------- 1 file changed, 5 insertions(+), 33 deletions(-)
arch/arm64/kvm/reset.c +5 -33
@@ -335,7 +335,7 @@ u32 get_kvm_ipa_limit(void)int kvm_set_ipa_limit (void ) { -unsigned int ipa_max, pa_max, va_max, parange, tgran_2; +unsigned int parange, tgran_2;u64 mmfr0; mmfr0 =read_sanitised_ftr_reg (SYS_ID_AA64MMFR0_EL1 );
@@ -372,38 +372,10 @@ int kvm_set_ipa_limit(void)break ; } - pa_max =id_aa64mmfr0_parange_to_phys_shift (parange); - -/* Clamp the IPA limit to the PA size supported by the kernel */ - ipa_max = (pa_max >PHYS_MASK_SHIFT ) ?PHYS_MASK_SHIFT : pa_max; -/* -* Since our stage2 table is dependent on the stage1 page table code, -* we must always honor the following condition: -* -* Number of levels in Stage1 >= Number of levels in Stage2. -* -* So clamp the ipa limit further down to limit the number of levels. -* Since we can concatenate upto 16 tables at entry level, we could -* go upto 4bits above the maximum VA addressable with the current -* number of levels. -*/ - va_max =PGDIR_SHIFT +PAGE_SHIFT -3 ; - va_max +=4 ; - -if (va_max < ipa_max) - ipa_max = va_max; - -/* -* If the final limit is lower than the real physical address -* limit of the CPUs, report the reason. -*/ -if (ipa_max < pa_max) -pr_info ("kvm: Limiting the IPA size due to kernel %s Address limit\n" , - (va_max < pa_max) ?"Virtual" :"Physical" ); - -WARN (ipa_max <KVM_PHYS_SHIFT , -"KVM IPA limit (%d bit) is smaller than default size\n" , ipa_max); - kvm_ipa_limit = ipa_max; + kvm_ipa_limit =id_aa64mmfr0_parange_to_phys_shift (parange); +WARN (kvm_ipa_limit <KVM_PHYS_SHIFT , +"KVM IPA limit (%d bit) is smaller than default size\n" , + kvm_ipa_limit);kvm_info ("IPA Size Limit: %dbits\n" , kvm_ipa_limit);return 0 ;
Signature · 6 lines
2.28.0.rc0.142.g3c755180ce-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Quoted 3 lines · Will Deacon
In terms of testing, I've done the usual Debian installer type things, but Quentin has also written targetted guest code [1] which we used to exercise dirty logging page-table collapse and coalescing.
...
Hi Quentin,
Any reason you didn't look into extending
tools/testing/selftests/kvm/dirty_log_test
and, if necessary, the AArch64 KVM selftests framework?
Thanks,
drew
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Hi Andrew,
Quoted 7 lines · Andrew Jones
Quoted 3 lines · Will Deacon
In terms of testing, I've done the usual Debian installer type things, but Quentin has also written targetted guest code [1] which we used to exercise dirty logging page-table collapse and coalescing.
...
Quoted 7 lines
Hi Quentin,
Any reason you didn't look into extending
tools/testing/selftests/kvm/dirty_log_testand, if necessary, the AArch64 KVM selftests framework?
I did run this particular test, but it didn't seem to exercise the code paths I wanted at the time, so I went with a custom-made implementation only to get this patch series out of the door as quickly as possible.
But I have no plan to maintain / push this further, and we should definitely be looking at extending the selftest instead to cover this use-case. I'll try to get to it at some point but there are a few things I need to finish off first :)
I hope that helps!
Thanks,
Quentin
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm