From: Yanan Wang <hidden> Date: 2021-06-17 10:58:31
Hello,
This series makes some efficiency improvement of guest stage-2 page
table code, and there are some test results to quantify the benefit.
Description for this series:
We currently uniformly permorm CMOs of D-cache and I-cache in function
user_mem_abort before calling the fault handlers. If we get concurrent
guest faults(e.g. translation faults, permission faults) or some really
unnecessary guest faults caused by BBM, CMOs for the first vcpu are
necessary while the others later are not.
By moving CMOs to the fault handlers, we can easily identify conditions
where they are really needed and avoid the unnecessary ones. As it's a
time consuming process to perform CMOs especially when flushing a block
range, so this solution reduces much load of kvm and improve efficiency
of the stage-2 page table code.
We can imagine two specific scenarios which will gain much benefit:
1) In a normal VM startup, this solution will improve the efficiency of
handling guest page faults incurred by vCPUs, when initially populating
stage-2 page tables.
2) After live migration, the heavy workload will be resumed on the
destination VM, however all the stage-2 page tables need to be rebuilt
at the moment. So this solution will ease the performance drop during
resuming stage.
The following are test results originally from v3 [1] to represent how
much benefit was introduced by movement of CMOs. We can use KVM selftest
to simulate a scenario of concurrent guest memory access and test the
execution time that KVM uses to create new stage-2 mappings, update the
existing mappings, split/rebuild huge mappings during/after dirty logging.
hardware platform: HiSilicon Kunpeng920 Server
host kernel: Linux mainline v5.12-rc2
test tools: KVM selftest [2]
[1] https://lore.kernel.org/lkml/20210326031654.3716-1-wangyanan55@huawei.com/
[2] https://lore.kernel.org/lkml/20210302125751.19080-1-wangyanan55@huawei.com/
cmdline: ./kvm_page_table_test -m 4 -s anonymous -b 1G -v 80
(80 vcpus, 1G memory, page mappings(normal 4K))
KVM_CREATE_MAPPINGS: before 104.35s -> after 90.42s +13.35%
KVM_UPDATE_MAPPINGS: before 78.64s -> after 75.45s + 4.06%
cmdline: ./kvm_page_table_test -m 4 -s anonymous_thp -b 20G -v 40
(40 vcpus, 20G memory, block mappings(THP 2M))
KVM_CREATE_MAPPINGS: before 15.66s -> after 6.92s +55.80%
KVM_UPDATE_MAPPINGS: before 178.80s -> after 123.35s +31.00%
KVM_REBUILD_BLOCKS: before 187.34s -> after 131.76s +30.65%
cmdline: ./kvm_page_table_test -m 4 -s anonymous_hugetlb_1gb -b 20G -v 40
(40 vcpus, 20G memory, block mappings(HUGETLB 1G))
KVM_CREATE_MAPPINGS: before 104.54s -> after 3.70s +96.46%
KVM_UPDATE_MAPPINGS: before 174.20s -> after 115.94s +33.44%
KVM_REBUILD_BLOCKS: before 103.95s -> after 2.96s +97.15%
---
Changelogs:
v6->v7:
- refine the new callback names and the related comments (Marc)
- refine the patch subject and commit messages
- v6: https://lore.kernel.org/lkml/20210616095200.38008-1-wangyanan55@huawei.com/
v5->v6:
- convert the guest CMO functions into callbacks in kvm_pgtable_mm_ops (Marc)
- drop patch #6 in v5 since we are stuffing topup into mmu_lock section (Quentin)
- rebased on latest kvmarm/tree
- v5: https://lore.kernel.org/lkml/20210415115032.35760-1-wangyanan55@huawei.com/
v4->v5:
- rebased on the latest kvmarm/tree to adapt to the new stage-2 page-table code
- v4: https://lore.kernel.org/lkml/20210409033652.28316-1-wangyanan55@huawei.com
---
Yanan Wang (4):
KVM: arm64: Introduce two cache maintenance callbacks
KVM: arm64: Introduce mm_ops member for structure stage2_attr_data
KVM: arm64: Tweak parameters of guest cache maintenance functions
KVM: arm64: Move guest CMOs to the fault handlers
arch/arm64/include/asm/kvm_mmu.h | 9 +----
arch/arm64/include/asm/kvm_pgtable.h | 42 ++++++++++++---------
arch/arm64/kvm/hyp/pgtable.c | 48 ++++++++++++++++++------
arch/arm64/kvm/mmu.c | 55 +++++++++++++---------------
4 files changed, 89 insertions(+), 65 deletions(-)
--
2.23.0
From: Yanan Wang <hidden> Date: 2021-06-17 10:58:37
To prepare for performing CMOs for guest stage-2 in the fault handlers
in pgtable.c, here introduce two cache maintenance callbacks in struct
kvm_pgtable_mm_ops. We also adjust the comment alignment for the
existing part but make no real content change at all.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/include/asm/kvm_pgtable.h | 42 +++++++++++++++++-----------
1 file changed, 25 insertions(+), 17 deletions(-)
From: Will Deacon <will@kernel.org> Date: 2021-06-17 12:39:23
On Thu, Jun 17, 2021 at 06:58:21PM +0800, Yanan Wang wrote:
quoted hunk
To prepare for performing CMOs for guest stage-2 in the fault handlers
in pgtable.c, here introduce two cache maintenance callbacks in struct
kvm_pgtable_mm_ops. We also adjust the comment alignment for the
existing part but make no real content change at all.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/include/asm/kvm_pgtable.h | 42 +++++++++++++++++-----------
1 file changed, 25 insertions(+), 17 deletions(-)
From: Marc Zyngier <maz@kernel.org> Date: 2021-06-17 14:20:31
On Thu, 17 Jun 2021 13:38:37 +0100,
Will Deacon [off-list ref] wrote:
On Thu, Jun 17, 2021 at 06:58:21PM +0800, Yanan Wang wrote:
quoted
To prepare for performing CMOs for guest stage-2 in the fault handlers
in pgtable.c, here introduce two cache maintenance callbacks in struct
kvm_pgtable_mm_ops. We also adjust the comment alignment for the
existing part but make no real content change at all.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/include/asm/kvm_pgtable.h | 42 +++++++++++++++++-----------
1 file changed, 25 insertions(+), 17 deletions(-)
On Thu, 17 Jun 2021 13:38:37 +0100,
Will Deacon [off-list ref] wrote:
quoted
On Thu, Jun 17, 2021 at 06:58:21PM +0800, Yanan Wang wrote:
quoted
To prepare for performing CMOs for guest stage-2 in the fault handlers
in pgtable.c, here introduce two cache maintenance callbacks in struct
kvm_pgtable_mm_ops. We also adjust the comment alignment for the
existing part but make no real content change at all.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/include/asm/kvm_pgtable.h | 42 +++++++++++++++++-----------
1 file changed, 25 insertions(+), 17 deletions(-)
Hi,
On Fri, Jun 18, 2021 at 2:52 AM wangyanan (Y) [off-list ref] wrote:
On 2021/6/17 22:20, Marc Zyngier wrote:
quoted
On Thu, 17 Jun 2021 13:38:37 +0100,
Will Deacon [off-list ref] wrote:
quoted
On Thu, Jun 17, 2021 at 06:58:21PM +0800, Yanan Wang wrote:
quoted
To prepare for performing CMOs for guest stage-2 in the fault handlers
in pgtable.c, here introduce two cache maintenance callbacks in struct
kvm_pgtable_mm_ops. We also adjust the comment alignment for the
existing part but make no real content change at all.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/include/asm/kvm_pgtable.h | 42 +++++++++++++++++-----------
1 file changed, 25 insertions(+), 17 deletions(-)
From: Marc Zyngier <maz@kernel.org> Date: 2021-06-18 11:10:37
On 2021-06-18 09:59, Fuad Tabba wrote:
Hi,
On Fri, Jun 18, 2021 at 2:52 AM wangyanan (Y) [off-list ref]
wrote:
quoted
On 2021/6/17 22:20, Marc Zyngier wrote:
quoted
On Thu, 17 Jun 2021 13:38:37 +0100,
Will Deacon [off-list ref] wrote:
quoted
On Thu, Jun 17, 2021 at 06:58:21PM +0800, Yanan Wang wrote:
quoted
To prepare for performing CMOs for guest stage-2 in the fault handlers
in pgtable.c, here introduce two cache maintenance callbacks in struct
kvm_pgtable_mm_ops. We also adjust the comment alignment for the
existing part but make no real content change at all.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/include/asm/kvm_pgtable.h | 42 +++++++++++++++++-----------
1 file changed, 25 insertions(+), 17 deletions(-)
OK, I've now aligned these callbacks to Fuad's naming:
[...]
* @dcache_clean_inval_poc: Clean and invalidate the data cache to the
PoC
* for the specified memory address range.
* @icache_inval_pou: Invalidate the instruction cache to the PoU
* for the specified memory address range.
*/
struct kvm_pgtable_mm_ops {
void* (*zalloc_page)(void *arg);
void* (*zalloc_pages_exact)(size_t size);
void (*free_pages_exact)(void *addr, size_t size);
void (*get_page)(void *addr);
void (*put_page)(void *addr);
int (*page_count)(void *addr);
void* (*phys_to_virt)(phys_addr_t phys);
phys_addr_t (*virt_to_phys)(void *addr);
void (*dcache_clean_inval_poc)(void *addr, size_t size);
void (*icache_inval_pou)(void *addr, size_t size);
};
and repainted everything else.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
From: Yanan Wang <hidden> Date: 2021-06-17 10:58:40
Adjust the parameter "kvm_pfn_t pfn" of __clean_dcache_guest_page
and __invalidate_icache_guest_page to "void *va", which paves the
way for converting these two guest CMO functions into callbacks in
structure kvm_pgtable_mm_ops. No functional change.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/include/asm/kvm_mmu.h | 9 ++-------
arch/arm64/kvm/mmu.c | 28 +++++++++++++++-------------
2 files changed, 17 insertions(+), 20 deletions(-)
@@ -203,16 +201,13 @@ static inline void __clean_dcache_guest_page(kvm_pfn_t pfn, unsigned long size)kvm_flush_dcache_to_poc(va,size);}-staticinlinevoid__invalidate_icache_guest_page(kvm_pfn_tpfn,-unsignedlongsize)+staticinlinevoid__invalidate_icache_guest_page(void*va,size_tsize){if(icache_is_aliasing()){/* any kind of VIPT cache */__flush_icache_all();}elseif(is_kernel_in_hyp_mode()||!icache_is_vpipt()){/* PIPT or VPIPT at EL2 (see comment in __kvm_tlb_flush_vmid_ipa) */-void*va=page_address(pfn_to_page(pfn));-invalidate_icache_range((unsignedlong)va,(unsignedlong)va+size);}
Hi Yanan,
On Thu, Jun 17, 2021 at 11:58 AM Yanan Wang [off-list ref] wrote:
quoted hunk
Adjust the parameter "kvm_pfn_t pfn" of __clean_dcache_guest_page
and __invalidate_icache_guest_page to "void *va", which paves the
way for converting these two guest CMO functions into callbacks in
structure kvm_pgtable_mm_ops. No functional change.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/include/asm/kvm_mmu.h | 9 ++-------
arch/arm64/kvm/mmu.c | 28 +++++++++++++++-------------
2 files changed, 17 insertions(+), 20 deletions(-)
@@ -203,16 +201,13 @@ static inline void __clean_dcache_guest_page(kvm_pfn_t pfn, unsigned long size)kvm_flush_dcache_to_poc(va,size);}-staticinlinevoid__invalidate_icache_guest_page(kvm_pfn_tpfn,-unsignedlongsize)+staticinlinevoid__invalidate_icache_guest_page(void*va,size_tsize){if(icache_is_aliasing()){/* any kind of VIPT cache */__flush_icache_all();}elseif(is_kernel_in_hyp_mode()||!icache_is_vpipt()){/* PIPT or VPIPT at EL2 (see comment in __kvm_tlb_flush_vmid_ipa) */-void*va=page_address(pfn_to_page(pfn));-invalidate_icache_range((unsignedlong)va,(unsignedlong)va+size);}
From: Yanan Wang <hidden> Date: 2021-06-17 10:58:42
We currently uniformly permorm CMOs of D-cache and I-cache in function
user_mem_abort before calling the fault handlers. If we get concurrent
guest faults(e.g. translation faults, permission faults) or some really
unnecessary guest faults caused by BBM, CMOs for the first vcpu are
necessary while the others later are not.
By moving CMOs to the fault handlers, we can easily identify conditions
where they are really needed and avoid the unnecessary ones. As it's a
time consuming process to perform CMOs especially when flushing a block
range, so this solution reduces much load of kvm and improve efficiency
of the stage-2 page table code.
We can imagine two specific scenarios which will gain much benefit:
1) In a normal VM startup, this solution will improve the efficiency of
handling guest page faults incurred by vCPUs, when initially populating
stage-2 page tables.
2) After live migration, the heavy workload will be resumed on the
destination VM, however all the stage-2 page tables need to be rebuilt
at the moment. So this solution will ease the performance drop during
resuming stage.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/kvm/hyp/pgtable.c | 38 +++++++++++++++++++++++++++++-------
arch/arm64/kvm/mmu.c | 37 ++++++++++++++---------------------
2 files changed, 46 insertions(+), 29 deletions(-)
From: Will Deacon <will@kernel.org> Date: 2021-06-17 12:46:08
On Thu, Jun 17, 2021 at 06:58:24PM +0800, Yanan Wang wrote:
quoted hunk
We currently uniformly permorm CMOs of D-cache and I-cache in function
user_mem_abort before calling the fault handlers. If we get concurrent
guest faults(e.g. translation faults, permission faults) or some really
unnecessary guest faults caused by BBM, CMOs for the first vcpu are
necessary while the others later are not.
By moving CMOs to the fault handlers, we can easily identify conditions
where they are really needed and avoid the unnecessary ones. As it's a
time consuming process to perform CMOs especially when flushing a block
range, so this solution reduces much load of kvm and improve efficiency
of the stage-2 page table code.
We can imagine two specific scenarios which will gain much benefit:
1) In a normal VM startup, this solution will improve the efficiency of
handling guest page faults incurred by vCPUs, when initially populating
stage-2 page tables.
2) After live migration, the heavy workload will be resumed on the
destination VM, however all the stage-2 page tables need to be rebuilt
at the moment. So this solution will ease the performance drop during
resuming stage.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/kvm/hyp/pgtable.c | 38 +++++++++++++++++++++++++++++-------
arch/arm64/kvm/mmu.c | 37 ++++++++++++++---------------------
2 files changed, 46 insertions(+), 29 deletions(-)
@@ -606,6 +618,14 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,stage2_put_pte(ptep,data->mmu,addr,level,mm_ops);}+/* Perform CMOs before installation of the guest stage-2 PTE */+if(mm_ops->clean_invalidate_dcache&&stage2_pte_cacheable(pgt,new))+mm_ops->clean_invalidate_dcache(kvm_pte_follow(new,mm_ops),+granule);++if(mm_ops->invalidate_icache&&stage2_pte_executable(new))+mm_ops->invalidate_icache(kvm_pte_follow(new,mm_ops),granule);
One thing I'm missing here is why we need the indirection via mm_ops. Are
there cases where we would want to pass a different function pointer for
invalidating the icache? If not, why not just call the function directly?
Same for the D side.
Will
From: Marc Zyngier <maz@kernel.org> Date: 2021-06-17 12:59:43
On Thu, 17 Jun 2021 13:45:57 +0100,
Will Deacon [off-list ref] wrote:
On Thu, Jun 17, 2021 at 06:58:24PM +0800, Yanan Wang wrote:
quoted
We currently uniformly permorm CMOs of D-cache and I-cache in function
user_mem_abort before calling the fault handlers. If we get concurrent
guest faults(e.g. translation faults, permission faults) or some really
unnecessary guest faults caused by BBM, CMOs for the first vcpu are
necessary while the others later are not.
By moving CMOs to the fault handlers, we can easily identify conditions
where they are really needed and avoid the unnecessary ones. As it's a
time consuming process to perform CMOs especially when flushing a block
range, so this solution reduces much load of kvm and improve efficiency
of the stage-2 page table code.
We can imagine two specific scenarios which will gain much benefit:
1) In a normal VM startup, this solution will improve the efficiency of
handling guest page faults incurred by vCPUs, when initially populating
stage-2 page tables.
2) After live migration, the heavy workload will be resumed on the
destination VM, however all the stage-2 page tables need to be rebuilt
at the moment. So this solution will ease the performance drop during
resuming stage.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/kvm/hyp/pgtable.c | 38 +++++++++++++++++++++++++++++-------
arch/arm64/kvm/mmu.c | 37 ++++++++++++++---------------------
2 files changed, 46 insertions(+), 29 deletions(-)
@@ -606,6 +618,14 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,stage2_put_pte(ptep,data->mmu,addr,level,mm_ops);}+/* Perform CMOs before installation of the guest stage-2 PTE */+if(mm_ops->clean_invalidate_dcache&&stage2_pte_cacheable(pgt,new))+mm_ops->clean_invalidate_dcache(kvm_pte_follow(new,mm_ops),+granule);++if(mm_ops->invalidate_icache&&stage2_pte_executable(new))+mm_ops->invalidate_icache(kvm_pte_follow(new,mm_ops),granule);
One thing I'm missing here is why we need the indirection via mm_ops. Are
there cases where we would want to pass a different function pointer for
invalidating the icache? If not, why not just call the function directly?
Same for the D side.
If we didn't do that, we'd end-up having to track whether the guest
context requires CMOs with additional flags, which is pretty ugly (see
v5 of this series for reference [1]).
It also means that we would have to drag the CM functions into the EL2
object, something that we don't need with this approach.
M.
[1] https://lore.kernel.org/r/20210415115032.35760-1-wangyanan55@huawei.com
--
Without deviation from the norm, progress is not possible.
From: Will Deacon <will@kernel.org> Date: 2021-06-17 13:21:24
On Thu, Jun 17, 2021 at 01:59:37PM +0100, Marc Zyngier wrote:
On Thu, 17 Jun 2021 13:45:57 +0100,
Will Deacon [off-list ref] wrote:
quoted
On Thu, Jun 17, 2021 at 06:58:24PM +0800, Yanan Wang wrote:
quoted
@@ -606,6 +618,14 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level, stage2_put_pte(ptep, data->mmu, addr, level, mm_ops); }+ /* Perform CMOs before installation of the guest stage-2 PTE */+ if (mm_ops->clean_invalidate_dcache && stage2_pte_cacheable(pgt, new))+ mm_ops->clean_invalidate_dcache(kvm_pte_follow(new, mm_ops),+ granule);++ if (mm_ops->invalidate_icache && stage2_pte_executable(new))+ mm_ops->invalidate_icache(kvm_pte_follow(new, mm_ops), granule);
One thing I'm missing here is why we need the indirection via mm_ops. Are
there cases where we would want to pass a different function pointer for
invalidating the icache? If not, why not just call the function directly?
Same for the D side.
If we didn't do that, we'd end-up having to track whether the guest
context requires CMOs with additional flags, which is pretty ugly (see
v5 of this series for reference [1]).
Fair enough, although the function pointers here _are_ being used as flags,
as they only ever have one of two possible values (NULL or the CMO function),
so it's a shame to bring in the indirect branch as well.
It also means that we would have to drag the CM functions into the EL2
object, something that we don't need with this approach.
I think it won't be long before we end up with CMO functions at EL2 and
you'd hope we'd be able to use the same code as EL1 for something like
that. But I also wouldn't want to put money on it...
Anyway, no strong opinion on this, it just jumped out when I skimmed the
patches.
Will
From: Marc Zyngier <maz@kernel.org> Date: 2021-06-17 13:37:37
On Thu, 17 Jun 2021 14:21:16 +0100,
Will Deacon [off-list ref] wrote:
On Thu, Jun 17, 2021 at 01:59:37PM +0100, Marc Zyngier wrote:
quoted
On Thu, 17 Jun 2021 13:45:57 +0100,
Will Deacon [off-list ref] wrote:
quoted
On Thu, Jun 17, 2021 at 06:58:24PM +0800, Yanan Wang wrote:
quoted
@@ -606,6 +618,14 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level, stage2_put_pte(ptep, data->mmu, addr, level, mm_ops); }+ /* Perform CMOs before installation of the guest stage-2 PTE */+ if (mm_ops->clean_invalidate_dcache && stage2_pte_cacheable(pgt, new))+ mm_ops->clean_invalidate_dcache(kvm_pte_follow(new, mm_ops),+ granule);++ if (mm_ops->invalidate_icache && stage2_pte_executable(new))+ mm_ops->invalidate_icache(kvm_pte_follow(new, mm_ops), granule);
One thing I'm missing here is why we need the indirection via mm_ops. Are
there cases where we would want to pass a different function pointer for
invalidating the icache? If not, why not just call the function directly?
Same for the D side.
If we didn't do that, we'd end-up having to track whether the guest
context requires CMOs with additional flags, which is pretty ugly (see
v5 of this series for reference [1]).
Fair enough, although the function pointers here _are_ being used as
flags, as they only ever have one of two possible values (NULL or
the CMO function), so it's a shame to bring in the indirect branch
as well.
What I hope eventually is to get rid of some of the FWB tracking we
have for the host in the protected case, and use the same abstraction.
quoted
It also means that we would have to drag the CM functions into the EL2
object, something that we don't need with this approach.
I think it won't be long before we end up with CMO functions at EL2 and
you'd hope we'd be able to use the same code as EL1 for something like
that. But I also wouldn't want to put money on it...
It we reach that stage, I'll be happy to try and move these function
into some shared location.
Anyway, no strong opinion on this, it just jumped out when I skimmed the
patches.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Hi Yanan,
On Thu, Jun 17, 2021 at 11:58 AM Yanan Wang [off-list ref] wrote:
We currently uniformly permorm CMOs of D-cache and I-cache in function
Nit: permorm -> perform
quoted hunk
user_mem_abort before calling the fault handlers. If we get concurrent
guest faults(e.g. translation faults, permission faults) or some really
unnecessary guest faults caused by BBM, CMOs for the first vcpu are
necessary while the others later are not.
By moving CMOs to the fault handlers, we can easily identify conditions
where they are really needed and avoid the unnecessary ones. As it's a
time consuming process to perform CMOs especially when flushing a block
range, so this solution reduces much load of kvm and improve efficiency
of the stage-2 page table code.
We can imagine two specific scenarios which will gain much benefit:
1) In a normal VM startup, this solution will improve the efficiency of
handling guest page faults incurred by vCPUs, when initially populating
stage-2 page tables.
2) After live migration, the heavy workload will be resumed on the
destination VM, however all the stage-2 page tables need to be rebuilt
at the moment. So this solution will ease the performance drop during
resuming stage.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/kvm/hyp/pgtable.c | 38 +++++++++++++++++++++++++++++-------
arch/arm64/kvm/mmu.c | 37 ++++++++++++++---------------------
2 files changed, 46 insertions(+), 29 deletions(-)
From: Yanan Wang <hidden> Date: 2021-06-17 10:58:55
Also add a mm_ops member for structure stage2_attr_data, since we
will move I-cache maintenance for guest stage-2 to the permission
path and as a result will need mm_ops for some callbacks.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/kvm/hyp/pgtable.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
Hi Yanan,
On Thu, Jun 17, 2021 at 11:58 AM Yanan Wang [off-list ref] wrote:
quoted hunk
Also add a mm_ops member for structure stage2_attr_data, since we
will move I-cache maintenance for guest stage-2 to the permission
path and as a result will need mm_ops for some callbacks.
Signed-off-by: Yanan Wang <redacted>
---
arch/arm64/kvm/hyp/pgtable.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
From: Marc Zyngier <maz@kernel.org> Date: 2021-06-18 11:38:38
On Thu, 17 Jun 2021 18:58:20 +0800, Yanan Wang wrote:
This series makes some efficiency improvement of guest stage-2 page
table code, and there are some test results to quantify the benefit.
Description for this series:
We currently uniformly permorm CMOs of D-cache and I-cache in function
user_mem_abort before calling the fault handlers. If we get concurrent
guest faults(e.g. translation faults, permission faults) or some really
unnecessary guest faults caused by BBM, CMOs for the first vcpu are
necessary while the others later are not.
[...]
Applied to next, thanks!
[1/4] KVM: arm64: Introduce two cache maintenance callbacks
commit: 6204004de3160900435bdb4b9a2fb8749a9277d2
[2/4] KVM: arm64: Introduce mm_ops member for structure stage2_attr_data
commit: a4d5ca5c7cd8fe85056b8cb838fbcb7e5a05f356
[3/4] KVM: arm64: Tweak parameters of guest cache maintenance functions
commit: 378e6a9c78a02b4b609846aa0afccf34d3038977
[4/4] KVM: arm64: Move guest CMOs to the fault handlers
commit: 25aa28691bb960a76f0cffd8862144a29487f6ff
Cheers,
M.
--
Without deviation from the norm, progress is not possible.