Re: [PATCH v2 1/6] x86/xpti: avoid copying L4 page table contents when possible

["Jan Beulich" <JBeulich@suse.com>]

>>> On 08.03.18 at 12:59, <jgross@suse.com> wrote:
> On 05/03/18 17:43, Jan Beulich wrote:
>>>>> On 02.03.18 at 09:13, <jgross@suse.com> wrote:
>>> @@ -3704,18 +3706,22 @@ long do_mmu_update(
>>>                          break;
>>>                      rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
>>>                                        cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
>>> -                    /*
>>> -                     * No need to sync if all uses of the page can be accounted
>>> -                     * to the page lock we hold, its pinned status, and uses on
>>> -                     * this (v)CPU.
>>> -                     */
>>> -                    if ( !rc && !cpu_has_no_xpti &&
>>> -                         ((page->u.inuse.type_info & PGT_count_mask) >
>>> -                          (1 + !!(page->u.inuse.type_info & PGT_pinned) +
>>> -                           (pagetable_get_pfn(curr->arch.guest_table) == mfn) 
>>> +
>>> -                           (pagetable_get_pfn(curr->arch.guest_table_user) ==
>>> -                            mfn))) )
> 
> Is it really possible this code is running with the user page table
> being active on the current cpu? I think this test can be dropped.

I'm not sure I understand: The check above isn't for what is
active on a CPU, but for what references are being held.
_Installing_ a root page table into ->arch.guest_table{,_user}
is when a reference is being obtained, not _loading_ the table
into CR3. (In theory the above could be extended to also
check vCPU-s other than current, but one would need to deal
with races; obviously pausing the other vCPU-s of the domain
wouldn't be a good idea, but that would be one possible way.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel