On 19/04/2023 09:20, Bertrand Marquis wrote:
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.
FWIW, I agree with Bertrand.
Cheers,
--
Julien Grall
