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

Re: [PATCH v2 2/2] xen/arm: Throw messages for unknown FP/SIMD implement ID





On 24/08/2020 17:57, Bertrand Marquis wrote:
Hi Julien,

Hi,


On 24 Aug 2020, at 14:34, Julien Grall <julien@xxxxxxx> wrote:

Hi Wei,

On 24/08/2020 04:28, Wei Chen wrote:
Arm ID_AA64PFR0_EL1 register provides two fields to describe CPU
FP/SIMD implementations. Currently, we exactly know the meaning of
0x0, 0x1 and 0xf of these fields. Xen treats value < 8 as FP/SIMD
features presented. If there is a value 0x2 bumped in the future,
Xen behaviors for value <= 0x1 can also take effect. But what Xen
done for value <= 0x1 may not always cover new value 0x2 required.

Right, but this will also happen with all the other features. This may actually 
confuse the users as they may think the rest of the features are fully 
supported which is not correct. For instance, dom0 will crash if you boot Xen 
on a SVE-capable hardware.

I would see this as an improvement already.

TBH, I only view this patch as a band-aid. I am OK with them but they need to be useful.

When I read "unknown value...", I have no clue whether the message is good or bad. It would be better to extend the message with what could go wrong. E.g "Unknown value X, this may result to corruption on the platform".

I would also consider to taint Xen as it may become unstable with this option set.

More could be done for SVE (and other bits) but this should be in another patch 
set.


We throw these messages to break the silence when Xen detected
unknown FP/SIMD IDs to notice user to check.

It feels a bit odd to me to print unknown for the FP/SIMD feature but not for 
all the rest.

IMHO, the right approach is to sanitize ID registers exposed to domains and 
only expose features we know are correctly handled.

I actually started to look into this last week because I came to an issue 
comparable to SVE with pointer authentication.
Maybe we should discuss this subject separately as clearing TID3 bit in HCR and 
emulating all ID registers is possible
but I want to check first if this could have big impacts on performances

I don't expect any performance drop. In Linux, they will cache all the values and use alternative to avoid runtime check.

I also don't expect any OS to use them at runtime in hotpath.

and see discuss how to design this as there
could be a huge amount of cases for example if we want to allow different 
parameters for different domains.

I would suggest to first consider a simple approach where we expose the same view of the ID registers to all the guests but it is sanitized.

We can then discuss whether we want to have a per-guest view of the ID registers and how to configure it.

Regarding the implementation, I personally quite like the Linux cpufeature framework. It is quite powerful and I believe would suit quite well Xen.

Cheers,

--
Julien Grall



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.