On 19.04.2023 09:31, Bertrand Marquis wrote: > Hi Jan, > >> On 19 Apr 2023, at 08:28, Jan Beulich <jbeul...@suse.com> 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
