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

[Juergen Gross <jgross@xxxxxxxx>]

On 08/03/18 13:47, Jan Beulich wrote:
>>>> On 08.03.18 at 12:59, <jgross@xxxxxxxx> wrote:
>> On 05/03/18 17:43, Jan Beulich wrote:
>>>>>> On 02.03.18 at 09:13, <jgross@xxxxxxxx> 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.)

Aah, sorry. Now I understand.

Thanks,


Juergen

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