Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Tue, Oct 4, 2016 at 1:41 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 01.10.16 at 21:05, <tamas.lengyel@xxxxxxxxxxxx> wrote:
>> However, I've found two other sources that need more attention:
>>
>> In x86/flushtlb.c the function flush_area_local invalidates all guest
>> TLBs as such:
>>
>>  if ( flags & (FLUSH_TLB|FLUSH_TLB_GLOBAL) )
>>     {
>>         if ( order == 0 )
>>         {
>> ...
>>         }
>>         else
>>         {
>>             u32 t = pre_flush();
>>             unsigned long cr4 = read_cr4();
>>
>>             hvm_flush_guest_tlbs();
>>
>> This flush here to me seems to be only warranted when FLUSH_TLB_GLOBAL
>> is requested.
>
> Why? The problem is that hvm_asid_flush_core() can't flush just
> non-global ones.
>
>> The other flush comes from the function write_cr3 also in
>> x86/flushtlb.c, which was introduced in the patch "[HVM][SVM] flush
>> all entries from guest ASIDs when xen writes CR3." commit id
>> eed63189dabd90abe422b0e94ab8854783329bed. From the commit message
>> however it is not entirely clear to me what exactly warrants having to
>> flush HVM guest TLBs and how that relates to shadow code. Commenting
>> this flush out made no difference to the guest or dom0, everything
>> works as expected. Of course, without understanding the real reason
>> for why this flush is here it is hard to judge whether this change
>> (re-)introduces some cornercase issue. It is worth noting this was
>> added even before VPID was introduced, so we might want to check
>> whether it is still required. AFAICT flushing the VPID in this case is
>> fine.
>
> Same problem here it seems - there's no way to leave global TLB
> entries unaffected, but we can't avoid the flush completely since
> non-global entries need to go away.
>

Hi Jan,
yes, I understand that is the case when you do need to flush a guest.
And yes, there seem to be paths that require to bump the tag of a
specific guest for certain events (mov-to-cr4 with paging mode changes
for example). What I'm poking at it here is that we invalidate the
guest TLBs for _all_ guests very frequently. I can't find an
explanation for why _that_ is required. AFAIK having the TLB tag
guarantees that no other guest or Xen will have a chance to bump into
stale entries given no guests or Xen share a TLB tag with each other.
So the only time I see that we would have to flush all guest TLBs is
when the tag overflows and we start from 1 again. What am I missing
here?

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel