Re: [Xen-devel] [PATCH v3 2/7] x86/xpti: don't flush TLB twice when switching to 64-bit pv context

[Juergen Gross <jgross@xxxxxxxx>]

On 22/03/18 15:50, Jan Beulich wrote:
>>>> On 21.03.18 at 13:51, <jgross@xxxxxxxx> wrote:
>> When switching to a 64-bit pv context the TLB is flushed twice today:
>> the first time when switching to the new address space in
>> write_ptbase(), the second time when switching to guest mode in
>> restore_to_guest.
>>
>> Avoid the first TLB flush in that case.
>>
>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
>> ---
>> V3:
>> - omit setting root_pgt_changed to false (Jan Beulich)
>> ---
>>  xen/arch/x86/mm.c | 9 ++++++++-
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>> index 352600ad73..8c944b33c9 100644
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -123,6 +123,7 @@
>>  #include <asm/io_apic.h>
>>  #include <asm/pci.h>
>>  #include <asm/guest.h>
>> +#include <asm/processor.h>
>>  
>>  #include <asm/hvm/grant_table.h>
>>  #include <asm/pv/grant_table.h>
>> @@ -507,8 +508,14 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>>  void write_ptbase(struct vcpu *v)
>>  {
>>      if ( this_cpu(root_pgt) && is_pv_vcpu(v) && !is_pv_32bit_vcpu(v) )
>> +    {
>>          get_cpu_info()->root_pgt_changed = true;
>> -    write_cr3(v->arch.cr3);
>> +        asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
>> +    }
>> +    else
>> +    {
>> +        write_cr3(v->arch.cr3);
>> +    }
> 
> Unnecessary braces. with that
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> (This could be taken care of while committing, but the patch
> depends on patch 1 anyway, which may see further
> transformation.)

Just realized it now: I have to re-introduce the conditionals I removed
on your behalf from patch 1, as otherwise I'd omit TLB flushing via
write_cr3() for 32-bit pv-domains and HVM-domains.

Therefor I'm removing your R-b in case you don't like that (patch 3
changes the conditional again, so I don't think that is really bad).


Juergen


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