Re: [Xen-devel] [PATCH v3 7/7] x86/tlb: use Xen L0 assisted TLB flush when available

["Roger Pau Monné" <roger.pau@citrix.com>]

On Tue, Jan 28, 2020 at 05:20:25PM +0000, Andrew Cooper wrote:
> On 28/01/2020 17:16, Roger Pau Monné wrote:
> >>>> OOI why isn't tlb_clk_enabled set to false when Xen determines to use L0
> >>>> assisted flush?
> >>> L0 assisted flush can fail (ie: return an error), and in that case Xen
> >>> would be better to continue using the timestamped tlb, as it could
> >>> avoid some flushes.
> >> Do you need to set tlb_clk_enabled in that case?
> > AFAICT it's safe to enable the TLB timestamps after being disabled,
> > but hypervisor_flush_tlb could fail intermittently with EBUSY in the
> > Xen implementation, and I don't really want that to cause spurious
> > enabling of the timestamps periodically.
> 
> What causes -EBUSY?

My bad, it's not EBUSY, it's ERESTART but that won't be returned to
the caller.

> I don't think it is reasonable for the hypercall to fail like that. 
> There is no circumstance ever where a TLB flush is wanted, and it is
> able to be deferred.

After this series ERESTART is only used by the shadow flush
implementation, and I'm not sure I'm confident enough to try to change
the shadow code in order to not do that, also because I think the
interest is likely much lower than for the HAP case.

> Forcing all callers to loop while busy is a terrible interface.

Well, the whole implementation of hvm_flush_vcpu_tlb is quite clumsy
because it attempts to pause each vCPU to be flushed, which for guests
with a high number of vCPUs makes it likely slower than just using a
shorthand IPI inside the guest.

Thanks, Roger.

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