Re: [Xen-devel] [PATCH v7 1/3] x86/tlb: introduce a flush HVM ASIDs flag

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Mar 20, 2020 at 03:59:35PM +0100, Jan Beulich wrote:
> On 20.03.2020 15:49, Roger Pau Monné wrote:
> > On Fri, Mar 20, 2020 at 02:27:36PM +0000, Julien Grall wrote:
> >>
> >>
> >> On 20/03/2020 14:22, Roger Pau Monné wrote:
> >>> static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp)
> >>> {
> >>>      cpumask_t mask;
> >>>
> >>>      cpumask_copy(&mask, &cpu_online_map);
> >>>      tlbflush_filter(&mask, tlbflush_timestamp);
> >>>      if ( !cpumask_empty(&mask) )
> >>>      {
> >>>          perfc_incr(need_flush_tlb_flush);
> >>> #if CONFIG_X86
> >>>          /*
> >>>           * filtered_flush_tlb_mask is used after modifying the p2m in
> >>>           * populate_physmap, Xen needs to trigger an ASID tickle as this 
> >>> is a
> >>>           * requirement on AMD hardware.
> >>>           */
> >>
> >> I don't think this comment is correct. populate_physmap() is only going to
> >> add entry in the P2M and therefore flush should not be needed.
> > 
> > Since this is strictly only adding entries I think you are right and
> > the ASID tickle could be avoided, as long as we can assert the gfn was
> > empty (or didn't have the valid bit set) previous to being populated.
> 
> While this may be true for x86, it's not guaranteed in general
> that non-present translations may not also be put into TLBs.
> So from common code there shouldn't be assumptions like this.

But as pointed out by Julien filtered_flush_tlb_mask is exclusively
used in combination with accumulate_tlbflush, which only cares about
the need_tlbflush in the page struct, and hence if pages added to the
physmap didn't had an owner you won't end up calling
filtered_flush_tlb_mask at all.

So the ASID tickle must be performed somewhere else, because gating
the ASID flush on whether the page had a previous owner is not
correct.

Thanks, Roger.

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