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

[Julien Grall <julien@xxxxxxx>]

Hi,

Answering to Jan's and Bertrand's e-mail at the same time.

On 19/04/2023 08:31, Bertrand Marquis wrote:
> > 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.
It is not clear to me why it is necessary for the system to boot in 
order to take corrective action. In the case of GRUB, you would likely 
have a fallback for a Linux baremetal boot just in case Xen crash at 
boot. So you can use the fallback to boot and update your command line 
in grub.cfg.
I agree this is less efficient, but it would be easier for a user to 
find out there was an issue in the command line passed.
> 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 ?
At the mode, I am not in favor of introducing a switch to relax the 
check. It will add more code in Xen for a benefit that is not clear to 
me (see above).
Cheers,

--
Julien Grall