Hi Jan, > On 19 Apr 2023, at 09:52, Jan Beulich <jbeul...@suse.com> wrote: > > 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?
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
