On Wed, 17 May 2017 14:18:16 +1000 David Gibson <da...@gibson.dropbear.id.au> wrote:
> On Mon, May 15, 2017 at 06:11:27PM +0200, Cédric Le Goater wrote:
> > >>> + int smt = kvmppc_smt_threads();
> > >>> + int nr_servers = DIV_ROUND_UP(max_cpus * smt, smp_threads);
> > >>
> > >> may be we should reintroduce nr_servers at the machine level ?
> > >>
> > >
> > > I had reintroduced it but then I realized it was only used in this
> > > function.
> >
> > nr_servers is also used when the device tree is populated with the
> > interrupt controller nodes. No big deal.
>
> Which is guest visible, so we should really make that stay the same
> for older machine types. I'd like to avoid re-introducing nr_servers
> as a property if we can, but maybe we can't.
>
Yes we can :) or at least maybe, if you can shed light on a guest
visible change introduced by this commit in 2.8:
commit 9b9a19080a6e548b91420ce7925f2ac81ef63ae8
Author: David Gibson <da...@gibson.dropbear.id.au>
Date: Thu Oct 20 16:07:56 2016 +1100
pseries: Move construction of /interrupt-controller fdt node
It changes the "ibm,interrupt-server-ranges" property in the device
tree from
{0, cpu_to_be32(max_cpus)}
to
{0, cpu_to_be32(xics->nr_servers)}
ie, {0, cpu_to_be32(DIV_ROUND_UP(max_cpus * smt, smp_threads))}
And indeed, if I start QEMU with
-smp cores=2,threads=4,maxcpus=16 -machine type=pseries-2.7,accel=kvm
the following is exposed to the guest with 2.7:
ibm,interrupt-server-ranges
00000000 00000010
and with 2.8 we get:
ibm,interrupt-server-ranges
00000000 00000020
LoPAPR B.6.9.1.1 says that the range (ie, the second number) "shall be the
number of contiguous server#s supported by the unit (this also corresponds
to the number of “reg” entries)". I'm inclined to think this maps to max_cpus
but I may be wrong... any clues ?
Cheers,
--
Greg
pgpIaBt1hlddS.pgp
Description: OpenPGP digital signature
