qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg Kurz
Subject: Re: [PATCH] spapr: Fix VSMT mode when it is not supported by the kernel
Date: Fri, 8 Nov 2019 18:23:15 +0100

On Fri, 8 Nov 2019 18:03:08 +0100
Laurent Vivier <address@hidden> wrote:

> On 08/11/2019 17:47, Greg Kurz wrote:
> > On Fri,  8 Nov 2019 16:40:35 +0100
> > Laurent Vivier <address@hidden> 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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]