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

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Jan,

> On 19 Apr 2023, at 09:52, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> 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?

I think this should depend:
- completely unknow: we can ignore
- not supported (sve while sve is not supported by the platform or Xen): we 
should not ignore

I agree that one could use custom command line arguments for lots of reasons
(in linux you can do that and get them back from /proc for example) but silently
ignoring a parameter that is known to Xen i do not think we should do.

I think in most cases, one could think its system is correctly running but 
could get
problems later (or in some cases even not have any) so having a clear error at 
the
beginning is a lot more clear.

Bertrand