All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Greg Kurz <groug@kaod.org>
Cc: "Laurent Vivier" <lvivier@redhat.com>,
	"Lukáš Doktor" <ldoktor@redhat.com>,
	"Juan Quintela" <quintela@redhat.com>,
	qemu-devel@nongnu.org,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-ppc@nongnu.org, clg@kaod.org
Subject: Re: [PATCH] spapr: Fix VSMT mode when it is not supported by the kernel
Date: Wed, 20 Nov 2019 15:36:53 +1100	[thread overview]
Message-ID: <20191120043653.GG5582@umbus.fritz.box> (raw)
In-Reply-To: <20191119164526.0e980a37@bahia.lan>

[-- Attachment #1: Type: text/plain, Size: 3216 bytes --]

On Tue, Nov 19, 2019 at 04:45:26PM +0100, Greg Kurz wrote:
> On Tue, 19 Nov 2019 15:06:51 +0100
> Laurent Vivier <lvivier@redhat.com> 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 <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.
> > >> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2019-11-20  4:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08 15:40 [PATCH] spapr: Fix VSMT mode when it is not supported by the kernel Laurent Vivier
2019-11-08 16:47 ` Greg Kurz
2019-11-08 17:03   ` Laurent Vivier
2019-11-08 17:23     ` Greg Kurz
2019-11-19  1:00   ` David Gibson
2019-11-19 14:06     ` Laurent Vivier
2019-11-19 15:45       ` Greg Kurz
2019-11-19 16:13         ` Lukáš Doktor
2019-11-20  4:39           ` David Gibson
2019-11-20  4:36         ` David Gibson [this message]
2019-11-20  7:49           ` Greg Kurz
2019-11-20  9:00           ` Laurent Vivier
2019-11-20 11:28             ` Laurent Vivier
2019-11-20 11:41               ` David Gibson
2019-11-20 11:58                 ` Laurent Vivier
2019-11-20 14:28                 ` Laurent Vivier
2019-11-21  2:02                   ` David Gibson
2019-11-20 12:47               ` Greg Kurz
2019-11-20 13:35                 ` Laurent Vivier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191120043653.GG5582@umbus.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=clg@kaod.org \
    --cc=dgilbert@redhat.com \
    --cc=groug@kaod.org \
    --cc=ldoktor@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.