@@ -105,28 +105,6 @@ void __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu,
105105 dsb (ish );
106106 isb ();
107107
108- /*
109- * If the host is running at EL1 and we have a VPIPT I-cache,
110- * then we must perform I-cache maintenance at EL2 in order for
111- * it to have an effect on the guest. Since the guest cannot hit
112- * I-cache lines allocated with a different VMID, we don't need
113- * to worry about junk out of guest reset (we nuke the I-cache on
114- * VMID rollover), but we do need to be careful when remapping
115- * executable pages for the same guest. This can happen when KSM
116- * takes a CoW fault on an executable page, copies the page into
117- * a page that was previously mapped in the guest and then needs
118- * to invalidate the guest view of the I-cache for that page
119- * from EL1. To solve this, we invalidate the entire I-cache when
120- * unmapping a page from a guest if we have a VPIPT I-cache but
121- * the host is running at EL1. As above, we could do better if
122- * we had the VA.
123- *
124- * The moral of this story is: if you have a VPIPT I-cache, then
125- * you should be running with VHE enabled.
126- */
127- if (icache_is_vpipt ())
128- icache_inval_all_pou ();
129-
130108 __tlb_switch_to_host (& cxt );
131109}
132110
@@ -157,28 +135,6 @@ void __kvm_tlb_flush_vmid_ipa_nsh(struct kvm_s2_mmu *mmu,
157135 dsb (nsh );
158136 isb ();
159137
160- /*
161- * If the host is running at EL1 and we have a VPIPT I-cache,
162- * then we must perform I-cache maintenance at EL2 in order for
163- * it to have an effect on the guest. Since the guest cannot hit
164- * I-cache lines allocated with a different VMID, we don't need
165- * to worry about junk out of guest reset (we nuke the I-cache on
166- * VMID rollover), but we do need to be careful when remapping
167- * executable pages for the same guest. This can happen when KSM
168- * takes a CoW fault on an executable page, copies the page into
169- * a page that was previously mapped in the guest and then needs
170- * to invalidate the guest view of the I-cache for that page
171- * from EL1. To solve this, we invalidate the entire I-cache when
172- * unmapping a page from a guest if we have a VPIPT I-cache but
173- * the host is running at EL1. As above, we could do better if
174- * we had the VA.
175- *
176- * The moral of this story is: if you have a VPIPT I-cache, then
177- * you should be running with VHE enabled.
178- */
179- if (icache_is_vpipt ())
180- icache_inval_all_pou ();
181-
182138 __tlb_switch_to_host (& cxt );
183139}
184140
@@ -205,10 +161,6 @@ void __kvm_tlb_flush_vmid_range(struct kvm_s2_mmu *mmu,
205161 dsb (ish );
206162 isb ();
207163
208- /* See the comment in __kvm_tlb_flush_vmid_ipa() */
209- if (icache_is_vpipt ())
210- icache_inval_all_pou ();
211-
212164 __tlb_switch_to_host (& cxt );
213165}
214166
@@ -246,18 +198,5 @@ void __kvm_flush_vm_context(void)
246198 /* Same remark as in __tlb_switch_to_guest() */
247199 dsb (ish );
248200 __tlbi (alle1is );
249-
250- /*
251- * VIPT and PIPT caches are not affected by VMID, so no maintenance
252- * is necessary across a VMID rollover.
253- *
254- * VPIPT caches constrain lookup and maintenance to the active VMID,
255- * so we need to invalidate lines with a stale VMID to avoid an ABA
256- * race after multiple rollovers.
257- *
258- */
259- if (icache_is_vpipt ())
260- asm volatile ("ic ialluis" );
261-
262201 dsb (ish );
263202}
0 commit comments