Re: [PATCH v6 1/9] mm: x86, arm64: add arch_has_hw_pte_young()

[Will Deacon <will@kernel.org>]

On Wed, Jan 05, 2022 at 01:47:08PM -0700, Yu Zhao wrote:
> On Wed, Jan 05, 2022 at 10:45:26AM +0000, Will Deacon wrote:
> > On Tue, Jan 04, 2022 at 01:22:20PM -0700, Yu Zhao wrote:
> > > diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> > > index 870c39537dd0..56e4ef5d95fa 100644
> > > --- a/arch/arm64/tools/cpucaps
> > > +++ b/arch/arm64/tools/cpucaps
> > > @@ -36,6 +36,7 @@ HAS_STAGE2_FWB
> > >  HAS_SYSREG_GIC_CPUIF
> > >  HAS_TLB_RANGE
> > >  HAS_VIRT_HOST_EXTN
> > > +HW_AF
> > >  HW_DBM
> > >  KVM_PROTECTED_MODE
> > >  MISMATCHED_CACHE_TYPE
> > 
> > As discussed in the previous threads, we really don't need the complexity
> > of the additional cap for the arm64 part. Please can you just use the
> > existing code instead? It's both simpler and, as you say, it's equivalent
> > for existing hardware.
> > 
> > That way, this patch just ends up being a renaming exercise and we're all
> > good.
> 
> No, renaming alone isn't enough. A caller needs to disable preemption
> before calling system_has_hw_af(), and I don't think it's reasonable
> to ask this caller to do it on x86 as well.
> 
> It seems you really prefer not to have HW_AF. So the best I can
> accommodate, considering other potential archs, e.g., risc-v (I do
> plan to provide benchmark results on risc-v, btw), is:
> 
>   static inline bool arch_has_hw_pte_young(bool local)
>   {
> 	bool hw_af;
> 
>   	if (local) {
>   		WARN_ON(preemptible());
>   		return cpu_has_hw_af();
>   	}
>   
> 	preempt_disable();
>   	hw_af = system_has_hw_af();
> 	preempt_enable();
> 
> 	return hw_af;
>   }
> 
> Or please give me something else I can call without disabling
> preemption, sounds good?

Sure thing, let me take a look. Do you have your series on a public git
tree someplace?

Cheers,

Will