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 <jbeul...@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 = {
>
