Re: [PATCH v14 04/39] arm64/sme: Provide ABI documentation for SME

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The 04/28/2022 10:19, Catalin Marinas wrote:
> On Tue, Apr 19, 2022 at 12:22:12PM +0100, Mark Brown wrote:
> > +* There are a number of optional SME features, presence of these is reported
> > +  through AT_HWCAP2 through:
> > +
> > +	HWCAP2_SME_I16I64
> > +	HWCAP2_SME_F64F64
> > +	HWCAP2_SME_I8I32
> > +	HWCAP2_SME_F16F32
> > +	HWCAP2_SME_B16F32
> > +	HWCAP2_SME_F32F32
> > +	HWCAP2_SME_FA64
> 
> Marc pointed out that in combination with FEAT_WFxT, we used all the
> HWCAP2 bits (32). While we are ok for now, we'll soon need to look into
> what to do when the next features turn up. Some options:
> 
> 1. Only provide HWCAP2_SME and let the ID_AA64SMFR0_EL1 features be
>    probed via MRS emulation. It doesn't solve the problem but it buys us
>    a bit of time.
> 
> 2. Don't bother with any new HWCAPs, just rely on MRS emulation (we have
>    HWCAP_CPUID advertising this).
> 
> 3. Start using the upper 32-bit of HWCAP and HWCAP2 (we initially didn't
>    go into these as there was a slight chance of merging ILP32). Does
>    the libc rely on the upper bits for anything? Or does it just assume
>    a 32-bit HWCAPs layout?

top 2 bits of a 64bit AT_HWCAP should be reserved for libc.
(glibc uses them internally)

otherwise glibc can work with 64bit hwcaps.

> 
> 4. Introduce HWCAP3.
> 
> Szabolcs, any thoughts?

i'd go with AT_HWCAP3 and keep using the bottom 32bit for now.
(this requires some new code in glibc, but not excessive)

thanks.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm



[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux