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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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