Re: [Xen-devel] [PATCH v2 4/6] xen/arm: cpufeature: Add helper to check constant caps

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 09/27/2018 11:34 PM, Stefano Stabellini wrote:
> On Wed, 26 Sep 2018, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 09/26/2018 05:53 PM, Stefano Stabellini wrote:
> > > On Tue, 25 Sep 2018, Julien Grall wrote:
> > > > Some capababilities are set right during boot and will never change
> > > > afterwards. At the moment, the function cpu_have_caps will check whether
> > > > the cap is enabled from the memory.
> > > >
> > > > It is possible to avoid the load from the memory by using an
> > > > ALTERNATIVE. With that the check is just reduced to 1 instruction.
> > > >
> > > > Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
> > > I enjoyed reading the patch :-)  But I don't think it is worth going
> > > into this extreme level of optimization. test_bit is efficient enough,
> > > right? What do you think we need to use alternatives just to check one
> > > bit?
> > We already have an helper using test_bit (see cpus_have_cap). However test_bit
> > requires to load the word from the memory. This is an overhead when the
> > decision never change after boot.
> >
> > One load may be insignificant by itself (thought may have a cache miss), but
> > if you are in hotpath this is a win in long term.
> >
> > The mechanism is very similar to static key but for the poor (I don't have
> > much time to implement better for now). We already use similar construction on
> > other places (see CHECK_WORKAROUND_HELPER).
> I like the mechanism and the little ALTERNATIVE trick.  I can see it
> could very useful in some cases. It is just that it is a bit of a waste
> to use it on SMCCC virtualization -- SMCCC calls cannot be done often
> enough for this to make a difference.
I would not be so sure ;). SMC can be called at *every* entry and exit 
into the hypervisor to apply SSBD workaround.
While SSBD will directly call arm_smccc_1_1_smc (and not the generic 
one), I would not rule out more hotpath with SMC call in it.
Cheers,

--
Julien Grall

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