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

Re: [PATCH] xen/arm: Missing N1/A76/A75 FP registers in vCPU context switch


  • To: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • From: André Przywara <andre.przywara@xxxxxxx>
  • Date: Tue, 18 Aug 2020 12:22:52 +0100
  • Autocrypt: addr=andre.przywara@xxxxxxx; prefer-encrypt=mutual; keydata= xsFNBFNPCKMBEAC+6GVcuP9ri8r+gg2fHZDedOmFRZPtcrMMF2Cx6KrTUT0YEISsqPoJTKld tPfEG0KnRL9CWvftyHseWTnU2Gi7hKNwhRkC0oBL5Er2hhNpoi8x4VcsxQ6bHG5/dA7ctvL6 kYvKAZw4X2Y3GTbAZIOLf+leNPiF9175S8pvqMPi0qu67RWZD5H/uT/TfLpvmmOlRzNiXMBm kGvewkBpL3R2clHquv7pB6KLoY3uvjFhZfEedqSqTwBVu/JVZZO7tvYCJPfyY5JG9+BjPmr+ REe2gS6w/4DJ4D8oMWKoY3r6ZpHx3YS2hWZFUYiCYovPxfj5+bOr78sg3JleEd0OB0yYtzTT esiNlQpCo0oOevwHR+jUiaZevM4xCyt23L2G+euzdRsUZcK/M6qYf41Dy6Afqa+PxgMEiDto ITEH3Dv+zfzwdeqCuNU0VOGrQZs/vrKOUmU/QDlYL7G8OIg5Ekheq4N+Ay+3EYCROXkstQnf YYxRn5F1oeVeqoh1LgGH7YN9H9LeIajwBD8OgiZDVsmb67DdF6EQtklH0ycBcVodG1zTCfqM AavYMfhldNMBg4vaLh0cJ/3ZXZNIyDlV372GmxSJJiidxDm7E1PkgdfCnHk+pD8YeITmSNyb 7qeU08Hqqh4ui8SSeUp7+yie9zBhJB5vVBJoO5D0MikZAODIDwARAQABzS1BbmRyZSBQcnp5 d2FyYSAoQVJNKSA8YW5kcmUucHJ6eXdhcmFAYXJtLmNvbT7CwXsEEwECACUCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheABQJTWSV8AhkBAAoJEAL1yD+ydue63REP/1tPqTo/f6StS00g NTUpjgVqxgsPWYWwSLkgkaUZn2z9Edv86BLpqTY8OBQZ19EUwfNehcnvR+Olw+7wxNnatyxo D2FG0paTia1SjxaJ8Nx3e85jy6l7N2AQrTCFCtFN9lp8Pc0LVBpSbjmP+Peh5Mi7gtCBNkpz KShEaJE25a/+rnIrIXzJHrsbC2GwcssAF3bd03iU41J1gMTalB6HCtQUwgqSsbG8MsR/IwHW XruOnVp0GQRJwlw07e9T3PKTLj3LWsAPe0LHm5W1Q+euoCLsZfYwr7phQ19HAxSCu8hzp43u zSw0+sEQsO+9wz2nGDgQCGepCcJR1lygVn2zwRTQKbq7Hjs+IWZ0gN2nDajScuR1RsxTE4WR lj0+Ne6VrAmPiW6QqRhliDO+e82riI75ywSWrJb9TQw0+UkIQ2DlNr0u0TwCUTcQNN6aKnru ouVt3qoRlcD5MuRhLH+ttAcmNITMg7GQ6RQajWrSKuKFrt6iuDbjgO2cnaTrLbNBBKPTG4oF D6kX8Zea0KvVBagBsaC1CDTDQQMxYBPDBSlqYCb/b2x7KHTvTAHUBSsBRL6MKz8wwruDodTM 4E4ToV9URl4aE/msBZ4GLTtEmUHBh4/AYwk6ACYByYKyx5r3PDG0iHnJ8bV0OeyQ9ujfgBBP B2t4oASNnIOeGEEcQ2rjzsFNBFNPCKMBEACm7Xqafb1Dp1nDl06aw/3O9ixWsGMv1Uhfd2B6 it6wh1HDCn9HpekgouR2HLMvdd3Y//GG89irEasjzENZPsK82PS0bvkxxIHRFm0pikF4ljIb 6tca2sxFr/H7CCtWYZjZzPgnOPtnagN0qVVyEM7L5f7KjGb1/o5EDkVR2SVSSjrlmNdTL2Rd zaPqrBoxuR/y/n856deWqS1ZssOpqwKhxT1IVlF6S47CjFJ3+fiHNjkljLfxzDyQXwXCNoZn BKcW9PvAMf6W1DGASoXtsMg4HHzZ5fW+vnjzvWiC4pXrcP7Ivfxx5pB+nGiOfOY+/VSUlW/9 GdzPlOIc1bGyKc6tGREH5lErmeoJZ5k7E9cMJx+xzuDItvnZbf6RuH5fg3QsljQy8jLlr4S6 8YwxlObySJ5K+suPRzZOG2+kq77RJVqAgZXp3Zdvdaov4a5J3H8pxzjj0yZ2JZlndM4X7Msr P5tfxy1WvV4Km6QeFAsjcF5gM+wWl+mf2qrlp3dRwniG1vkLsnQugQ4oNUrx0ahwOSm9p6kM CIiTITo+W7O9KEE9XCb4vV0ejmLlgdDV8ASVUekeTJkmRIBnz0fa4pa1vbtZoi6/LlIdAEEt PY6p3hgkLLtr2GRodOW/Y3vPRd9+rJHq/tLIfwc58ZhQKmRcgrhtlnuTGTmyUqGSiMNfpwAR AQABwsFfBBgBAgAJBQJTTwijAhsMAAoJEAL1yD+ydue64BgP/33QKczgAvSdj9XTC14wZCGE U8ygZwkkyNf021iNMj+o0dpLU48PIhHIMTXlM2aiiZlPWgKVlDRjlYuc9EZqGgbOOuR/pNYA JX9vaqszyE34JzXBL9DBKUuAui8z8GcxRcz49/xtzzP0kH3OQbBIqZWuMRxKEpRptRT0wzBL O31ygf4FRxs68jvPCuZjTGKELIo656/Hmk17cmjoBAJK7JHfqdGkDXk5tneeHCkB411p9WJU vMO2EqsHjobjuFm89hI0pSxlUoiTL0Nuk9Edemjw70W4anGNyaQtBq+qu1RdjUPBvoJec7y/ EXJtoGxq9Y+tmm22xwApSiIOyMwUi9A1iLjQLmngLeUdsHyrEWTbEYHd2sAM2sqKoZRyBDSv ejRvZD6zwkY/9nRqXt02H1quVOP42xlkwOQU6gxm93o/bxd7S5tEA359Sli5gZRaucpNQkwd KLQdCvFdksD270r4jU/rwR2R/Ubi+txfy0dk2wGBjl1xpSf0Lbl/KMR5TQntELfLR4etizLq Xpd2byn96Ivi8C8u9zJruXTueHH8vt7gJ1oax3yKRGU5o2eipCRiKZ0s/T7fvkdq+8beg9ku fDO4SAgJMIl6H5awliCY2zQvLHysS/Wb8QuB09hmhLZ4AifdHyF1J5qeePEhgTA+BaUbiUZf i4aIXCH3Wv6K
  • Cc: Wei Chen <Wei.Chen@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Steve Capper <Steve.Capper@xxxxxxx>, Kaly Xin <Kaly.Xin@xxxxxxx>, nd <nd@xxxxxxx>
  • Delivery-date: Tue, 18 Aug 2020 11:23:22 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 18/08/2020 11:13, Bertrand Marquis wrote:

Hi,

>> On 18 Aug 2020, at 10:42, André Przywara <andre.przywara@xxxxxxx> wrote:
>>
>> On 18/08/2020 10:25, Bertrand Marquis wrote:
>>
>> Hi,
>>
>>>> On 18 Aug 2020, at 10:14, André Przywara <andre.przywara@xxxxxxx> wrote:
>>>>
>>>> On 18/08/2020 04:11, Wei Chen wrote:
>>>>
>>>> Hi Wei,
>>>>
>>>>> Xen has cpu_has_fp/cpu_has_simd to detect whether the CPU supports
>>>>> FP/SIMD or not. But currently, this two MACROs only consider value 0
>>>>> of ID_AA64PFR0_EL1.FP/SIMD as FP/SIMD features enabled. But for CPUs
>>>>> that support FP/SIMD and half-precision floating-point features, the
>>>>> ID_AA64PFR0_EL1.FP/SIMD are 1. For these CPUs, xen will treat them as
>>>>> no FP/SIMD support. In this case, the vfp_save/restore_state will not
>>>>> take effect.
>>>>>
>>>>> Unfortunately, Cortex-N1/A76/A75 are the CPUs support FP/SIMD and
>>>>> half-precision floatiing-point. Their ID_AA64PFR0_EL1.FP/SMID are 1
>>>>> (see Arm ARM DDI0487F.b, D13.2.64). In this case, on N1/A76/A75
>>>>> platforms, Xen will always miss the float pointer registers save/restore.
>>>>> If different vCPUs are running on the same pCPU, the float pointer
>>>>> registers will be corrupted randomly.
>>>>
>>>> That's a good catch, thanks for working this out!
>>>>
>>>> One thing below...
>>>>
>>>>> This patch fixes Xen on these new cores.
>>>>>
>>>>> Signed-off-by: Wei Chen <wei.chen@xxxxxxx>
>>>>> ---
>>>>> xen/include/asm-arm/cpufeature.h | 4 ++--
>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/xen/include/asm-arm/cpufeature.h 
>>>>> b/xen/include/asm-arm/cpufeature.h
>>>>> index 674beb0353..588089e5ae 100644
>>>>> --- a/xen/include/asm-arm/cpufeature.h
>>>>> +++ b/xen/include/asm-arm/cpufeature.h
>>>>> @@ -13,8 +13,8 @@
>>>>> #define cpu_has_el2_64    (boot_cpu_feature64(el2) >= 1)
>>>>> #define cpu_has_el3_32    (boot_cpu_feature64(el3) == 2)
>>>>> #define cpu_has_el3_64    (boot_cpu_feature64(el3) >= 1)
>>>>> -#define cpu_has_fp        (boot_cpu_feature64(fp) == 0)
>>>>> -#define cpu_has_simd      (boot_cpu_feature64(simd) == 0)
>>>>> +#define cpu_has_fp        (boot_cpu_feature64(fp) <= 1)
>>>>> +#define cpu_has_simd      (boot_cpu_feature64(simd) <= 1)
>>>>
>>>> But this is only good until the next feature bump. I think we should be
>>>> more future-proof here. The architecture describes those two fields as
>>>> "signed"[1], and guarantees that "if value >= 0" is a valid test for the
>>>> feature. Which means we are good as long as the sign bit (bit 3) is
>>>> clear, which translates into:
>>>> #define cpu_has_fp        (boot_cpu_feature64(fp) < 8)
>>>> Same for simd.
>>>>
>>>
>>> We cannot really be sure that a new version introduced will require the
>>> same context save/restore so it might dangerous to claim we support
>>> something we have no idea about.
>>
>> I am pretty sure we can, because this is what the FP feature describes.
>> If a feature bump would introduce a larger state to be saved and
>> restored, that would be covered by a new field, look at AdvSIMD and SVE
>> for examples.
>> The feature number would only be bumped if it's compatible:
>> ====================
>> · The field holds a signed value.
>> · The field value 0xF indicates that the feature is not implemented.
>> · The field value 0x0 indicates that the feature is implemented.
>> · Software that depends on the feature can use the test:
>>      if value >= 0 {  // Software features that depend on the presence
>> of the hardware feature }
>> ====================
>> (ARMv8 ARM D13.1.3)
>>
>> And this is how Linux handles this.
> 
> Then changing the code to use <8 should be ok.

Thanks. Another angle to look at this:
Using "< 8" will never be worse than "<= 1", since we only derive the
existence of the floating point registers from it. The moment we see a 2
in this register field, the "<= 1" would definitely fail to save/restore
the FP registers again. But the ARM ARM guarantees that those registers
are still around (since "value >= 0" hits, so the feature is present, as
shown above).
The theoretical worst case with "< 8" would be that it would not cover
*enough* state, but as described above this will never happen, with this
particular FP/SIMD field.

Cheers,
Andre

>>> I agree though about the analysis on the fact that values under 8 should
>>> be valid but only 0 and 1 currently exist [1], other values are reserved.
>>>
>>> So I would vote to keep the 1 for now there.
>>>
>>> Cheers
>>> Bertrand
>>>
>>> [1] 
>>> https://developer.arm.com/docs/ddi0595/h/aarch64-system-registers/id_aa64pfr0_el1
> 




 


Rackspace

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