Re: [PATCH] x86/hvm: Remove callback from paging->flush_tlb() hook

["Durrant, Paul" <xadimgnik@xxxxxxxxx>]

On 18/11/2021 11:19, Andrew Cooper wrote:
> On 18/11/2021 10:45, Jan Beulich wrote:
> > On 17.11.2021 19:26, Andrew Cooper wrote:
> > > TLB flushing is a hotpath, and function pointer calls are
> > > expensive (especially under repoline) for what amounts to an identity
> > > transform on the data.  Just pass the vcpu_bitmap bitmap directly.
> > >
> > > As we use NULL for all rather than none, introduce a flush_vcpu() helper to
> > > avoid the risk of logical errors from opencoding the expression.  This also
> > > means the viridian callers can avoid writing an all-ones bitmap for the
> > > flushing logic to consume.
> > I think you want to clarify that you convert only one of the two ways of
> > specifying "all". The other (HV_GENERIC_SET_ALL as consumed by
> > hv_vpset_to_vpmask()) could also be converted, but this would be a bit
> > more involved. I have no idea which of the two Windows would typically
> > use, nor why there are two mechanisms in the first place.
> Oh - I'd not spotted that path.  It is well hidden away from
> HV_FLUSH_ALL_PROCESSORS.
>
> Giving how windows APIs typically evolve,
> HVCALL_FLUSH_VIRTUAL_ADDRESS_{SPACE,LIST} where first.  It has a limit
> of 64 vCPUs, and the VpSet sparse form is clearly catering to massive
> numbers of vCPUs.
>
> I'd expect to see both paths used, so we ought to see about optimising
> that too, in due course.
In my experience, yes, it only uses the sparse version if you have more 
than 64 vCPUs.
  Paul

> > > No functional change.
> > >
> > > Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> Thanks.
>
> ~Andrew