Re: [RFC PATCH 0/8] SVE feature for arm guests

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

> On 11 Jan 2023, at 16:59, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi Luca,
> 
> On 11/01/2023 14:38, Luca Fancellu wrote:
>> This serie is introducing the possibility for Dom0 and DomU guests to use
>> sve/sve2 instructions.
>> SVE feature introduces new instruction and registers to improve performances 
>> on
>> floating point operations.
>> The SVE feature is advertised using the ID_AA64PFR0_EL1 register, SVE field, 
>> and
>> when available the ID_AA64ZFR0_EL1 register provides additional information
>> about the implemented version and other SVE feature.
>> New registers added by the SVE feature are Z0-Z31, P0-P15, FFR, ZCR_ELx.
>> Z0-Z31 are scalable vector register whose size is implementation defined and
>> goes from 128 bits to maximum 2048, the term vector length will be used to 
>> refer
>> to this quantity.
>> P0-P15 are predicate registers and the size is the vector length divided by 
>> 8,
>> same size is the FFR (First Fault Register).
>> ZCR_ELx is a register that can control and restrict the maximum vector length
>> used by the <x> exception level and all the lower exception levels, so for
>> example EL3 can restrict the vector length usable by EL3,2,1,0.
>> The platform has a maximum implemented vector length, so for every value
>> written in ZCR register, if this value is above the implemented length, then 
>> the
>> lower value will be used. The RDVL instruction can be used to check what 
>> vector
>> length is the HW using after setting ZCR.
>> For an SVE guest, the V0-V31 registers are part of the Z0-Z31, so there is no
>> need to save them separately, saving Z0-Z31 will save implicitly also V0-V31.
>> SVE usage can be trapped using a flag in CPTR_EL2, hence in this serie the
>> register is added to the domain state, to be able to trap only the guests 
>> that
>> are not allowed to use SVE.
>> This serie is introducing a command line parameter to enable Dom0 to use SVE 
>> and
>> to set its maximum vector length that by default is 0 which means the guest 
>> is
>> not allowed to use SVE. Values from 128 to 2048 mean the guest can use SVE 
>> with
>> the selected value used as maximum allowed vector length (which could be 
>> lower
>> if the implemented one is lower).
>> For DomUs, an XL parameter with the same way of use is introduced and a 
>> dom0less
>> DTB binding is created.
>> The context switch is the most critical part because there can be big 
>> registers
>> to be saved, in this serie an easy approach is used and the context is
>> saved/restored every time for the guests that are allowed to use SVE.
> 
> This would be OK for an initial approach. But I would be worry to officially 
> support SVE because of the potential large impact on other users.
> 
> What's the long term plan?

Hi Julien,

For the future we can plan some work and decide together how to handle the 
context switch,
we might need some suggestions from you (arm maintainers) to design that part 
in the best
way for functional and security perspective.

For now we might flag the feature as unsupported, explaining in the Kconfig 
help that switching
between SVE and non-SVE guests, or between SVE guests, might add latency 
compared to
switching between non-SVE guests.

What do you think?

Cheers,
Luca

> 
> Cheers,
> 
> -- 
> Julien Grall