Re: [PATCH v5 00/12] SVE feature for arm guests

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.04.2023 09:31, Bertrand Marquis wrote:
> Hi Jan,
> 
>> On 19 Apr 2023, at 08:28, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 18.04.2023 16:25, Julien Grall wrote:
>>> On 18/04/2023 14:13, Bertrand Marquis wrote:
>>>> On this serie I would like to open a discussion on how to handle the 
>>>> vector size
>>>> and the corresponding command line / configuration / device tree 
>>>> parameters.
>>>>
>>>> In general the user must either give a vector size it wants or has a 
>>>> solution to
>>>> just request the maximum supported size.
>>>>
>>>> In the current implementation if a size bigger than the supported one is 
>>>> provided:
>>>> - we silently disable SVE for dom0
>>>> - we silently disable SVE for dom0less
>>>> - we do not create a guest when done through tools
>>>>
>>>> This is not completely coherent and i think we should aim for a coherent 
>>>> behaviour
>>>> unless we have arguments for this status.
>>>
>>> +1.
>>>
>>>> Is there any good reason to silently disable for Dom0 and dom0less only ?
>>>>
>>>> I see some possible solutions here:
>>>>
>>>> - modify parameter behaviour to use the supported size if parameter is 
>>>> bigger than
>>>> it. This would at least keep SVE enabled if a VM depends on it and could 
>>>> simplify
>>>> some of the handling by using 2048 to use the maximum supported size.
>>>
>>> My concern with this approach and the third one is the user may take 
>>> some time to realize the problem in the xl.cfg. So...
>>>
>>>>
>>>> - coherently stop if the parameter value is not supported (including if 
>>>> sve is
>>>> not supported)
>>>
>>> ... this is my preferred approach because it would be clear that the 
>>> value passed to Xen is bogus.
>>
>> I did say earlier on that this comes with its own downside of preventing
>> boot to complete for no real reason. It's all Arm code, so you're fine
>> to ignore me, but in similar situations elsewhere (sorry, don't recall a
>> concrete example off the top of my head) we've aimed to allow the system
>> to boot, for the admin to then take corrective action if/as needed.
> 
> But a guest depending on the feature will just crash later when booting.
> This is making the assumption that guests are all able to properly adapt
> to different hardware possibilities. 
> This might be the case when you have a full Linux but if you consider an
> embedded use case, if something is activated due to command line parameters
> or configuration ones, it should not be expected that those are ignored I 
> think.
> 
> There are definitely 2 different needs here, maybe we need to have something
> like a "strict" switch to allow both use cases ?

Possibly. Yet along what I've said before - would you then also mean that to
fail boot upon encountering entirely unknown command line options?

Jan