On Fri, 8 Nov 2019 18:03:08 +0100 Laurent Vivier <lviv...@redhat.com> wrote:
> On 08/11/2019 17:47, Greg Kurz wrote: > > On Fri, 8 Nov 2019 16:40:35 +0100 > > Laurent Vivier <lviv...@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 >
