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: David Gibson
Subject: Re: [PATCH] spapr: Fix VSMT mode when it is not supported by the kernel
Date: Wed, 20 Nov 2019 15:36:53 +1100
User-agent: Mutt/1.12.1 (2019-06-15)

On Tue, Nov 19, 2019 at 04:45:26PM +0100, Greg Kurz wrote:
> On Tue, 19 Nov 2019 15:06:51 +0100
> Laurent Vivier <address@hidden> wrote:
> 
> > On 19/11/2019 02:00, David Gibson wrote:
> > > On Fri, Nov 08, 2019 at 05:47:59PM +0100, 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.
> > >> What happens if we migrate between an older kernel and a recent one ?
> > > 
> > > Right.  We're really trying to remove instaces of such behaviour.  I'd
> > > prefer to completely revert Greg's original patch than to re-introduce
> > > host configuration dependency into the guest configuration..
> > > 
> > >> 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 ?
> > > 
> > > ..adjusting the test case like this might be a better idea, though.
> > > 
> > > What's the test setup where we're using the old kernel?  I really only
> > > applied the original patch on the guess that we didn't really care
> > > about kernels that old.  The fact you've hit this in practice makes me
> > > doubt that assumption.
> > > 
> > 
> > The way to fix the tests is to add "-smp threads=8" on the command line
> > (for all tests, so basically in qtest_init_without_qmp_handshake(), and
> > it will impact all the machine types), and we have to check if it is
> 
> Ohhh... it isn't possible to initialize Qtest with machine specific
> properties ? That's a bit unfortunate :-\

Uhh... I don't see why we can't.  Couldn't we just put either -machine
vsmt=8 or -smp 8 into the cmd_src / cmd_dst printfs() in the
strcmp(arch, "ppc64") case?

> > ppc64/pseries to do that, and there it becomes a little bit complicated
> > for a so small piece of code.
> > 
> > So I think the best to do is to revert Greg's patch.
> > 
> 
> I'm okay with that since this patch doesn't bring much for the moment.
> 
> But soon, ie. linux-5.5 hopefully, KVM will allow to configure the number
> of presenters in the XIVE and XICS-on-XIVE devices on POWER9. Combined
> with this patch, it will allow to drastically reduce the consumption of
> resources in the XIVE HW, which currently limits the number of VMs that
> can run concurrently with an in-kernel irqchip. So I hope the 'make check'
> you're willing to fix is worth it :-), and BTW you didn't answer David's
> question about the test setup.
> 

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

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