[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PATCH][XTF] XSA-286: fix PAE variant of test
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@xxxxxxxx> --- 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 = {
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |