Re: [PATCH] spapr: Fix VSMT mode when it is not supported by the kernel

[Greg Kurz <groug@kaod.org>]

On Fri, 8 Nov 2019 18:03:08 +0100
Laurent Vivier <lvivier@redhat.com> wrote:

> On 08/11/2019 17:47, Greg Kurz wrote:
> > On Fri,  8 Nov 2019 16:40:35 +0100
> > Laurent Vivier <lvivier@redhat.com> wrote:
> > 
> >> Commit 29cb4187497d sets by default the VSMT to smp_threads,
> >> but older kernels (< 4.13) don't support that.
> >>
> >> We can reasonably restore previous behavior with this kernel
> >> to allow to run QEMU as before.
> >>
> >> If VSMT is not supported, VSMT will be set to MAX(8, smp_threads)
> >> as it is done for previous machine types (< pseries-4.2)
> >>
> > 
> > It is usually _bad_ to base the machine behavior on host capabilities.
> 
> This is already the case, statically: your patch guesses the kernel
> always support VSMT. So you can't start the machine (and thus can't
> migrate it to/from).
> 

Failing to start the machine is okay. The thing we want to avoid is
to successfully start the guest and discover later on we cannot
migrate it.

> > What happens if we migrate between an older kernel and a recent one ?
> 
> I think migration is supported correctly only if parameters are
> explicitly set. So this is not our case.
> 

Hence my suggestion to introspect...

> > I understand this is to fix tests/migration-test on older kernels.
> > Couldn't this be achieved with migration-test doing some introspection
> > and maybe pass vsmt=8 on the QEMU command line ?
> 
> It could be a little bit complicated to instrospect this.

... ah, you likely know migration-test better than I do :)

> We could also set by default vsmt=8 at the test level.
> 

This would mean that we don't test an exact default setup, but this
would still test most of the migration paths. I guess this could be
an acceptable trade-off only if 'make check' must *really* support
older kernels.

> Thanks,
> Laurent
>