L3 entry updates aren't specified to take immediate effect in PAE mode:
On bare metal, only the next CR3 load actually loads the PDPTEs, and a
32-bit Xen also wouldn't immediately propagate new entries into the
PDPTEs. Them taking immediate effect (leaving aside the need to flush
the TLB) on 64-bit Xen is merely to not complicate the hypervisor
implementation more than necessary. Guests cannot depend on such
behavior, and hence this test shouldn't either.
Insert the hypercall equivalent of a CR3 reload into the multicall.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
With this, cb199cc7de98 ('Revert "x86/PV32: avoid TLB flushing after
mod_l3_entry()" and "x86/PV: restrict TLB flushing after
mod_l[234]_entry()"') should imo be reverted from the Xen tree. The
claim was wrong that the test was correct and hypervisor code flawed.
--- a/tests/xsa-286/main.c
+++ b/tests/xsa-286/main.c
@@ -128,9 +128,18 @@ void test_main(void)
*
* - update_va_mapping(addr, 0, INLVPG)
* - mmu_update(&l3t[slot], l2t2)
+ * - (PAE only) new_baseptr(cr3)
* - update_va_mapping(addr, gfn0 | AD|WR|P, INLVPG)
*/
mu[0].val = pte_from_virt(l2t2, PF_SYM(AD, RW, P));
+#ifdef __i386__
+ mmuext_op_t mx[] = {
+ {
+ .cmd = MMUEXT_NEW_BASEPTR,
+ .arg1.mfn = read_cr3() >> PAGE_SHIFT,
+ },
+ };
+#endif
intpte_t nl1e = pte_from_gfn(pfn_to_mfn(0), PF_SYM(AD, RW, P));
multicall_entry_t multi[] = {
{
@@ -153,6 +162,17 @@ void test_main(void)
DOMID_SELF,
},
},
+#ifdef __i386__
+ {
+ .op = __HYPERVISOR_mmuext_op,
+ .args = {
+ _u(mx),
+ ARRAY_SIZE(mx),
+ _u(NULL),
+ DOMID_SELF,
+ },
+ },
+#endif
{
.op = __HYPERVISOR_update_va_mapping,
.args = {
On 17.05.2021 15:22, Jan Beulich wrote: > L3 entry updates aren't specified to take immediate effect in PAE mode: > On bare metal, only the next CR3 load actually loads the PDPTEs, and a > 32-bit Xen also wouldn't immediately propagate new entries into the > PDPTEs. Them taking immediate effect (leaving aside the need to flush > the TLB) on 64-bit Xen is merely to not complicate the hypervisor > implementation more than necessary. Guests cannot depend on such > behavior, and hence this test shouldn't either. > > Insert the hypercall equivalent of a CR3 reload into the multicall. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > With this, cb199cc7de98 ('Revert "x86/PV32: avoid TLB flushing after > mod_l3_entry()" and "x86/PV: restrict TLB flushing after > mod_l[234]_entry()"') should imo be reverted from the Xen tree. The > claim was wrong that the test was correct and hypervisor code flawed. Ping? I know you've expressed your disagreement with things stated above, but I'm afraid you're still on the hook to actually prove some of the claims you've made. Thanks, Jan > --- a/tests/xsa-286/main.c > +++ b/tests/xsa-286/main.c > @@ -128,9 +128,18 @@ void test_main(void) > * > * - update_va_mapping(addr, 0, INLVPG) > * - mmu_update(&l3t[slot], l2t2) > + * - (PAE only) new_baseptr(cr3) > * - update_va_mapping(addr, gfn0 | AD|WR|P, INLVPG) > */ > mu[0].val = pte_from_virt(l2t2, PF_SYM(AD, RW, P)); > +#ifdef __i386__ > + mmuext_op_t mx[] = { > + { > + .cmd = MMUEXT_NEW_BASEPTR, > + .arg1.mfn = read_cr3() >> PAGE_SHIFT, > + }, > + }; > +#endif > intpte_t nl1e = pte_from_gfn(pfn_to_mfn(0), PF_SYM(AD, RW, P)); > multicall_entry_t multi[] = { > { > @@ -153,6 +162,17 @@ void test_main(void) > DOMID_SELF, > }, > }, > +#ifdef __i386__ > + { > + .op = __HYPERVISOR_mmuext_op, > + .args = { > + _u(mx), > + ARRAY_SIZE(mx), > + _u(NULL), > + DOMID_SELF, > + }, > + }, > +#endif > { > .op = __HYPERVISOR_update_va_mapping, > .args = { >
© 2016 - 2024 Red Hat, Inc.