[{"id":1770851,"web_url":"http://patchwork.ozlabs.org/comment/1770851/","msgid":"<20170919022719.GH27153@umbus>","list_archive_url":null,"date":"2017-09-19T02:27:19","subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Mon, Sep 11, 2017 at 07:12:15PM +0200, Cédric Le Goater wrote:\n> Start with a couple of attributes for the XIVE sPAPR controller\n> model. The number of provisionned IRQ is necessary to size the\n> different internal XIVE tables, the number of CPUs is also.\n> \n> Signed-off-by: Cédric Le Goater \n\n[snip]\n\n> +static void spapr_xive_realize(DeviceState *dev, Error **errp)\n> +{\n> + sPAPRXive *xive = SPAPR_XIVE(dev);\n> +\n> + if (!xive->nr_targets) {\n> + error_setg(errp, \"Number of interrupt targets needs to be greater 0\");\n> + return;\n> + }\n> + /* We need to be able to allocate at least the IPIs */\n> + if (!xive->nr_irqs || xive->nr_irqs < xive->nr_targets) {\n> + error_setg(errp, \"Number of interrupts too small\");\n> + return;\n> + }\n> +}\n> +\n> +static Property spapr_xive_properties[] = {\n> + DEFINE_PROP_UINT32(\"nr-irqs\", sPAPRXive, nr_irqs, 0),\n> + DEFINE_PROP_UINT32(\"nr-targets\", sPAPRXive, nr_targets, 0),\n\nI'm a bit uneasy about the number of targets having to be set in\nadvance: this can make life awkward when CPUs are hotplugged. I know\nthere's something similar in xics, but it has caused some hassles, and\nwe're starting to move away from it.\n\nDo you really need this?","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"f30z15LG\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxKNg2PM9z9sNw\n\tfor ;\n\tTue, 19 Sep 2017 20:48:33 +1000 (AEST)","from localhost ([::1]:41413 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duG4q-0002II-Aj\n\tfor incoming@patchwork.ozlabs.org; Tue, 19 Sep 2017 06:48:28 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:51166)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duFtW-0001Fe-3C\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 06:36:49 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duFtQ-0002nI-LC\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 06:36:46 -0400","from ozlabs.org ([2401:3900:2:1::2]:60931)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duFtQ-0002jB-Aq; Tue, 19 Sep 2017 06:36:40 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xxK6p4mtmz9t34; Tue, 19 Sep 2017 20:36:33 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1505817394;\n\tbh=mhlSYw37GiHrXXunkcFg1iZhxXKL2x6Su936nS6cSv4=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=f30z15LGCamtUrI58OurD2UTgMrprF2uwSYpXXac7dBCKlESaCUyW/xCtJ0Bn//yY\n\tXQWrGwRkqTmAxluyEdEsYi90GjTyNLyIuqP2GEU9uPXkQa3grfm4+f73pW4S0e3iMo\n\ttq3iKfHLdH2/NvAfrRk8Sk2UGylcGEer5pIUjMnY=","Date":"Tue, 19 Sep 2017 12:27:19 +1000","From":"David Gibson ","To":"=?iso-8859-1?q?C=E9dric?= Le Goater ","Message-ID":"<20170919022719.GH27153@umbus>","References":"<20170911171235.29331-1-clg@kaod.org>\n\t<20170911171235.29331-2-clg@kaod.org>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"y0Ed1hDcWxc3B7cn\"","Content-Disposition":"inline","In-Reply-To":"<20170911171235.29331-2-clg@kaod.org>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2401:3900:2:1::2","Subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Alexey Kardashevskiy , qemu-ppc@nongnu.org,\n\tqemu-devel@nongnu.org, Alexander Graf ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771017,"web_url":"http://patchwork.ozlabs.org/comment/1771017/","msgid":"","list_archive_url":null,"date":"2017-09-19T13:15:44","subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","submitter":{"id":68548,"url":"http://patchwork.ozlabs.org/api/people/68548/","name":"Cédric Le Goater","email":"clg@kaod.org"},"content":"On 09/19/2017 04:27 AM, David Gibson wrote:\n> On Mon, Sep 11, 2017 at 07:12:15PM +0200, Cédric Le Goater wrote:\n>> Start with a couple of attributes for the XIVE sPAPR controller\n>> model. The number of provisionned IRQ is necessary to size the\n>> different internal XIVE tables, the number of CPUs is also.\n>>\n>> Signed-off-by: Cédric Le Goater \n> \n> [snip]\n> \n>> +static void spapr_xive_realize(DeviceState *dev, Error **errp)\n>> +{\n>> + sPAPRXive *xive = SPAPR_XIVE(dev);\n>> +\n>> + if (!xive->nr_targets) {\n>> + error_setg(errp, \"Number of interrupt targets needs to be greater 0\");\n>> + return;\n>> + }\n>> + /* We need to be able to allocate at least the IPIs */\n>> + if (!xive->nr_irqs || xive->nr_irqs < xive->nr_targets) {\n>> + error_setg(errp, \"Number of interrupts too small\");\n>> + return;\n>> + }\n>> +}\n>> +\n>> +static Property spapr_xive_properties[] = {\n>> + DEFINE_PROP_UINT32(\"nr-irqs\", sPAPRXive, nr_irqs, 0),\n>> + DEFINE_PROP_UINT32(\"nr-targets\", sPAPRXive, nr_targets, 0),\n> \n> I'm a bit uneasy about the number of targets having to be set in\n> advance: this can make life awkward when CPUs are hotplugged. I know\n> there's something similar in xics, but it has caused some hassles, and\n> we're starting to move away from it.\n> \n> Do you really need this?\n> \n\nSome of the internal table size depend on the number of cpus \ndefined for the machine. When the sPAPRXive object is instantiated, \nwe use xics_max_server_number() to get the max number of cpus\nprovisioned.\n\nC.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxP5F0Y5Wz9sBZ\n\tfor ;\n\tTue, 19 Sep 2017 23:35:29 +1000 (AEST)","from localhost ([::1]:42913 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duIgR-0007SK-6a\n\tfor incoming@patchwork.ozlabs.org; Tue, 19 Sep 2017 09:35:27 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:36569)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duINc-000169-9G\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 09:16:06 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duINY-0004pI-1d\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 09:16:00 -0400","from 8.mo3.mail-out.ovh.net ([87.98.172.249]:60015)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1duINX-0004oA-S0\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 09:15:55 -0400","from player797.ha.ovh.net (b9.ovh.net [213.186.33.59])\n\tby mo3.mail-out.ovh.net (Postfix) with ESMTP id 6A1D0159601\n\tfor ; Tue, 19 Sep 2017 15:15:54 +0200 (CEST)","from zorba.kaod.org (deibp9eh1--blueice1n4.emea.ibm.com\n\t[195.212.29.166]) (Authenticated sender: postmaster@kaod.org)\n\tby player797.ha.ovh.net (Postfix) with ESMTPSA id 9AB782E0087;\n\tTue, 19 Sep 2017 15:15:45 +0200 (CEST)"],"To":"David Gibson ","References":"<20170911171235.29331-1-clg@kaod.org>\n\t<20170911171235.29331-2-clg@kaod.org> <20170919022719.GH27153@umbus>","From":"=?utf-8?q?C=C3=A9dric_Le_Goater?= ","Message-ID":"","Date":"Tue, 19 Sep 2017 15:15:44 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170919022719.GH27153@umbus>","Content-Type":"text/plain; charset=windows-1252","Content-Language":"en-US","X-Ovh-Tracer-Id":"1768225807581940600","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrfeelledrheejgdeigecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"87.98.172.249","Subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Alexey Kardashevskiy , qemu-ppc@nongnu.org,\n\tqemu-devel@nongnu.org, Alexander Graf ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1773492,"web_url":"http://patchwork.ozlabs.org/comment/1773492/","msgid":"<20170922110040.GP4998@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-22T11:00:40","subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Tue, Sep 19, 2017 at 03:15:44PM +0200, Cédric Le Goater wrote:\n> On 09/19/2017 04:27 AM, David Gibson wrote:\n> > On Mon, Sep 11, 2017 at 07:12:15PM +0200, Cédric Le Goater wrote:\n> >> Start with a couple of attributes for the XIVE sPAPR controller\n> >> model. The number of provisionned IRQ is necessary to size the\n> >> different internal XIVE tables, the number of CPUs is also.\n> >>\n> >> Signed-off-by: Cédric Le Goater \n> > \n> > [snip]\n> > \n> >> +static void spapr_xive_realize(DeviceState *dev, Error **errp)\n> >> +{\n> >> + sPAPRXive *xive = SPAPR_XIVE(dev);\n> >> +\n> >> + if (!xive->nr_targets) {\n> >> + error_setg(errp, \"Number of interrupt targets needs to be greater 0\");\n> >> + return;\n> >> + }\n> >> + /* We need to be able to allocate at least the IPIs */\n> >> + if (!xive->nr_irqs || xive->nr_irqs < xive->nr_targets) {\n> >> + error_setg(errp, \"Number of interrupts too small\");\n> >> + return;\n> >> + }\n> >> +}\n> >> +\n> >> +static Property spapr_xive_properties[] = {\n> >> + DEFINE_PROP_UINT32(\"nr-irqs\", sPAPRXive, nr_irqs, 0),\n> >> + DEFINE_PROP_UINT32(\"nr-targets\", sPAPRXive, nr_targets, 0),\n> > \n> > I'm a bit uneasy about the number of targets having to be set in\n> > advance: this can make life awkward when CPUs are hotplugged. I know\n> > there's something similar in xics, but it has caused some hassles, and\n> > we're starting to move away from it.\n> > \n> > Do you really need this?\n> > \n> \n> Some of the internal table size depend on the number of cpus \n> defined for the machine.\n\nWhich ones? My impression was that there needed to be at least #cpus\n* #priority-levels EQs, but there could be more than that, so it was\nno longer as tightly bound to the number if \"interrupt servers\" as xics.\n\n> When the sPAPRXive object is instantiated, \n> we use xics_max_server_number() to get the max number of cpus\n> provisioned.\n> \n> C.\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"LFLV9gry\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xz9y70y24z9sPm\n\tfor ;\n\tFri, 22 Sep 2017 21:20:31 +1000 (AEST)","from localhost ([::1]:58056 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dvM0T-0004it-5X\n\tfor incoming@patchwork.ozlabs.org; Fri, 22 Sep 2017 07:20:29 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:37847)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dvLzr-0004iA-Dz\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 07:19:52 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dvLzo-0007DY-64\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 07:19:51 -0400","from ozlabs.org ([103.22.144.67]:48179)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dvLzn-0007Ab-27; Fri, 22 Sep 2017 07:19:48 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xz9xC1dnYz9t16; Fri, 22 Sep 2017 21:19:43 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1506079183;\n\tbh=S/++kJnJ/fMnUPklTC/msqHUJfe1P0jcZyM+bv2KSeo=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=LFLV9gryyFUqc/Av8T7SMPYbAzNhqHq7kUMVYFJmlXqnp/E13x06ntqK/WOyUP+a4\n\tdqSNkf5RVK34nSjAhSiCqiaagokzo8rRK4pL7lG2/I6lsTxO07wqR54fvqN+DHl4fc\n\tIwB6kOuHo2bt+0e8Mo4Su2+iUcnXd8t5Flg5yqg8=","Date":"Fri, 22 Sep 2017 21:00:40 +1000","From":"David Gibson ","To":"=?iso-8859-1?q?C=E9dric?= Le Goater ","Message-ID":"<20170922110040.GP4998@umbus.fritz.box>","References":"<20170911171235.29331-1-clg@kaod.org>\n\t<20170911171235.29331-2-clg@kaod.org>\n\t<20170919022719.GH27153@umbus>\n\t","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"gQt10JDuGyDb0HQ5\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"103.22.144.67","Subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Alexey Kardashevskiy , qemu-ppc@nongnu.org,\n\tqemu-devel@nongnu.org, Alexander Graf ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1773563,"web_url":"http://patchwork.ozlabs.org/comment/1773563/","msgid":"","list_archive_url":null,"date":"2017-09-22T12:42:07","subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","submitter":{"id":68548,"url":"http://patchwork.ozlabs.org/api/people/68548/","name":"Cédric Le Goater","email":"clg@kaod.org"},"content":"On 09/22/2017 01:00 PM, David Gibson wrote:\n> On Tue, Sep 19, 2017 at 03:15:44PM +0200, Cédric Le Goater wrote:\n>> On 09/19/2017 04:27 AM, David Gibson wrote:\n>>> On Mon, Sep 11, 2017 at 07:12:15PM +0200, Cédric Le Goater wrote:\n>>>> Start with a couple of attributes for the XIVE sPAPR controller\n>>>> model. The number of provisionned IRQ is necessary to size the\n>>>> different internal XIVE tables, the number of CPUs is also.\n>>>>\n>>>> Signed-off-by: Cédric Le Goater \n>>>\n>>> [snip]\n>>>\n>>>> +static void spapr_xive_realize(DeviceState *dev, Error **errp)\n>>>> +{\n>>>> + sPAPRXive *xive = SPAPR_XIVE(dev);\n>>>> +\n>>>> + if (!xive->nr_targets) {\n>>>> + error_setg(errp, \"Number of interrupt targets needs to be greater 0\");\n>>>> + return;\n>>>> + }\n>>>> + /* We need to be able to allocate at least the IPIs */\n>>>> + if (!xive->nr_irqs || xive->nr_irqs < xive->nr_targets) {\n>>>> + error_setg(errp, \"Number of interrupts too small\");\n>>>> + return;\n>>>> + }\n>>>> +}\n>>>> +\n>>>> +static Property spapr_xive_properties[] = {\n>>>> + DEFINE_PROP_UINT32(\"nr-irqs\", sPAPRXive, nr_irqs, 0),\n>>>> + DEFINE_PROP_UINT32(\"nr-targets\", sPAPRXive, nr_targets, 0),\n>>>\n>>> I'm a bit uneasy about the number of targets having to be set in\n>>> advance: this can make life awkward when CPUs are hotplugged. I know\n>>> there's something similar in xics, but it has caused some hassles, and\n>>> we're starting to move away from it.\n>>>\n>>> Do you really need this?\n>>>\n>>\n>> Some of the internal table size depend on the number of cpus \n>> defined for the machine.\n> \n> Which ones? My impression was that there needed to be at least #cpus\n> * #priority-levels EQs, but there could be more than that, \n\neuh no, not in spapr mode at least. There are 8 queues per cpu.\n\n> so it was no longer as tightly bound to the number if \"interrupt servers\"> as xics.\n\nah. I think I see what you mean, that we could allocate them on the \nfly when needed by some hcalls ? \n\nThe other place where I use the nr_targets is to provision the \nIRQ numbers for the IPIs but that could probably be done in some \nother way, specially it there is a IRQ allocator at the machine level.\n\nC. \n>> When the sPAPRXive object is instantiated, \n>> we use xics_max_server_number() to get the max number of cpus\n>> provisioned.\n>>\n>> C.\n>>\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xzCyH3YjZz9s9Y\n\tfor ;\n\tFri, 22 Sep 2017 22:50:47 +1000 (AEST)","from localhost ([::1]:58708 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dvNPp-000737-Jv\n\tfor incoming@patchwork.ozlabs.org; Fri, 22 Sep 2017 08:50:45 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:59881)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dvNHg-0000RZ-Dq\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 08:42:21 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dvNHb-0003lu-Fz\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 08:42:20 -0400","from 1.mo179.mail-out.ovh.net ([178.33.111.220]:56710)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dvNHb-0003jm-9a\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 08:42:15 -0400","from player690.ha.ovh.net (b6.ovh.net [213.186.33.56])\n\tby mo179.mail-out.ovh.net (Postfix) with ESMTP id 9D037629F6\n\tfor ; Fri, 22 Sep 2017 14:42:13 +0200 (CEST)","from zorba.kaod.org (LFbn-1-2231-173.w90-76.abo.wanadoo.fr\n\t[90.76.52.173]) (Authenticated sender: postmaster@kaod.org)\n\tby player690.ha.ovh.net (Postfix) with ESMTPSA id 11761540080;\n\tFri, 22 Sep 2017 14:42:08 +0200 (CEST)"],"To":"David Gibson ","References":"<20170911171235.29331-1-clg@kaod.org>\n\t<20170911171235.29331-2-clg@kaod.org> <20170919022719.GH27153@umbus>\n\t\n\t<20170922110040.GP4998@umbus.fritz.box>","From":"=?utf-8?q?C=C3=A9dric_Le_Goater?= ","Message-ID":"","Date":"Fri, 22 Sep 2017 14:42:07 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170922110040.GP4998@umbus.fritz.box>","Content-Type":"text/plain; charset=windows-1252","Content-Language":"en-US","X-Ovh-Tracer-Id":"370702546729274232","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrfeelledrieeggdehjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"178.33.111.220","Subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Alexey Kardashevskiy , qemu-ppc@nongnu.org,\n\tqemu-devel@nongnu.org, Alexander Graf ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1775132,"web_url":"http://patchwork.ozlabs.org/comment/1775132/","msgid":"<20170926035423.GH12504@umbus>","list_archive_url":null,"date":"2017-09-26T03:54:23","subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Fri, Sep 22, 2017 at 02:42:07PM +0200, Cédric Le Goater wrote:\n> On 09/22/2017 01:00 PM, David Gibson wrote:\n> > On Tue, Sep 19, 2017 at 03:15:44PM +0200, Cédric Le Goater wrote:\n> >> On 09/19/2017 04:27 AM, David Gibson wrote:\n> >>> On Mon, Sep 11, 2017 at 07:12:15PM +0200, Cédric Le Goater wrote:\n> >>>> Start with a couple of attributes for the XIVE sPAPR controller\n> >>>> model. The number of provisionned IRQ is necessary to size the\n> >>>> different internal XIVE tables, the number of CPUs is also.\n> >>>>\n> >>>> Signed-off-by: Cédric Le Goater \n> >>>\n> >>> [snip]\n> >>>\n> >>>> +static void spapr_xive_realize(DeviceState *dev, Error **errp)\n> >>>> +{\n> >>>> + sPAPRXive *xive = SPAPR_XIVE(dev);\n> >>>> +\n> >>>> + if (!xive->nr_targets) {\n> >>>> + error_setg(errp, \"Number of interrupt targets needs to be greater 0\");\n> >>>> + return;\n> >>>> + }\n> >>>> + /* We need to be able to allocate at least the IPIs */\n> >>>> + if (!xive->nr_irqs || xive->nr_irqs < xive->nr_targets) {\n> >>>> + error_setg(errp, \"Number of interrupts too small\");\n> >>>> + return;\n> >>>> + }\n> >>>> +}\n> >>>> +\n> >>>> +static Property spapr_xive_properties[] = {\n> >>>> + DEFINE_PROP_UINT32(\"nr-irqs\", sPAPRXive, nr_irqs, 0),\n> >>>> + DEFINE_PROP_UINT32(\"nr-targets\", sPAPRXive, nr_targets, 0),\n> >>>\n> >>> I'm a bit uneasy about the number of targets having to be set in\n> >>> advance: this can make life awkward when CPUs are hotplugged. I know\n> >>> there's something similar in xics, but it has caused some hassles, and\n> >>> we're starting to move away from it.\n> >>>\n> >>> Do you really need this?\n> >>>\n> >>\n> >> Some of the internal table size depend on the number of cpus \n> >> defined for the machine.\n> > \n> > Which ones? My impression was that there needed to be at least #cpus\n> > * #priority-levels EQs, but there could be more than that, \n> \n> euh no, not in spapr mode at least. There are 8 queues per cpu.\n\nOk.\n\n> > so it was no longer as tightly bound to the number if \"interrupt servers\"> as xics.\n> \n> ah. I think I see what you mean, that we could allocate them on the \n> fly when needed by some hcalls ?\n\nNot at hcall time, no, but at cpu hot(un)plug time I was wondering if we\ncould (de)allocate them then.\n\n> The other place where I use the nr_targets is to provision the \n> IRQ numbers for the IPIs but that could probably be done in some \n> other way, specially it there is a IRQ allocator at the machine\n> level.\n\nHm, ok.\n\n> \n> C. \n> >> When the sPAPRXive object is instantiated, \n> >> we use xics_max_server_number() to get the max number of cpus\n> >> provisioned.\n> >>\n> >> C.\n> >>\n> > \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"ajVIlGc9\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y1RvK2dwxz9t3Z\n\tfor ;\n\tTue, 26 Sep 2017 13:55:57 +1000 (AEST)","from localhost ([::1]:45479 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dwgyR-0005Ch-IO\n\tfor incoming@patchwork.ozlabs.org; Mon, 25 Sep 2017 23:55:55 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:39190)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dwgy4-0005BY-7D\n\tfor qemu-devel@nongnu.org; Mon, 25 Sep 2017 23:55:33 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dwgy0-0003Tu-9u\n\tfor qemu-devel@nongnu.org; Mon, 25 Sep 2017 23:55:32 -0400","from ozlabs.org ([103.22.144.67]:38261)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dwgxz-0003Q7-J3; Mon, 25 Sep 2017 23:55:28 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3y1Rtj1nYvz9t49; Tue, 26 Sep 2017 13:55:25 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1506398125;\n\tbh=xVfGBJGWO6TaIaWxewqfpi3iwh6gDgiQ+8zXeJCgcB8=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=ajVIlGc9b9ZYPb8Y3imc6yyYU1fQvihJLwdLySuqplfAnPfVNi6vRrik1Py+8KzSx\n\tsgB4DEKGF6brO9fjy0K/LrCpGkZiFQ9TbqjNh0d7A5FDiGRGnl+KybywcpMyQORe8R\n\tOPy0XafjX03FB+iMcfj2xIF+Ni59QMCh9i45LElw=","Date":"Tue, 26 Sep 2017 13:54:23 +1000","From":"David Gibson ","To":"=?iso-8859-1?q?C=E9dric?= Le Goater ","Message-ID":"<20170926035423.GH12504@umbus>","References":"<20170911171235.29331-1-clg@kaod.org>\n\t<20170911171235.29331-2-clg@kaod.org>\n\t<20170919022719.GH27153@umbus>\n\t\n\t<20170922110040.GP4998@umbus.fritz.box>\n\t","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"/9ZOS6odDaRI+0hI\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"103.22.144.67","Subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Alexey Kardashevskiy , qemu-ppc@nongnu.org,\n\tqemu-devel@nongnu.org, Alexander Graf ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1775304,"web_url":"http://patchwork.ozlabs.org/comment/1775304/","msgid":"<1506419102.2541.11.camel@kernel.crashing.org>","list_archive_url":null,"date":"2017-09-26T09:45:02","subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","submitter":{"id":38,"url":"http://patchwork.ozlabs.org/api/people/38/","name":"Benjamin Herrenschmidt","email":"benh@kernel.crashing.org"},"content":"On Tue, 2017-09-26 at 13:54 +1000, David Gibson wrote:\n> > > \n> > > Which ones? My impression was that there needed to be at least #cpus\n> > > * #priority-levels EQs, but there could be more than that, \n> > \n> > euh no, not in spapr mode at least. There are 8 queues per cpu.\n> \n> Ok.\n\nThere's a HW feature of XIVE in DD2.x that I will start exploiting soon\nthat sacrifices a queue btw, keep that in mind.\n\nWe should probably only expose 0...6 to guests, not 0...7.\n\n> > > so it was no longer as tightly bound to the number if \"interrupt servers\"> as xics.\n> > \n> > ah. I think I see what you mean, that we could allocate them on the \n> > fly when needed by some hcalls ?\n> \n> Not at hcall time, no, but at cpu hot(un)plug time I was wondering if we\n> could (de)allocate them then.\n> \n> > The other place where I use the nr_targets is to provision the \n> > IRQ numbers for the IPIs but that could probably be done in some \n> > other way, specially it there is a IRQ allocator at the machine\n> > level.\n> \n> Hm, ok.\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y1bgY63Jvz9tX8\n\tfor ;\n\tTue, 26 Sep 2017 19:46:17 +1000 (AEST)","from localhost ([::1]:46393 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dwmRT-0001q7-Sm\n\tfor incoming@patchwork.ozlabs.org; Tue, 26 Sep 2017 05:46:15 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:35265)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dwmR3-0001pl-Vf\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 05:45:51 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dwmR1-0002cQ-DU\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 05:45:50 -0400","from gate.crashing.org ([63.228.1.57]:33549)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dwmR1-0002Y7-3x; Tue, 26 Sep 2017 05:45:47 -0400","from localhost (localhost.localdomain [127.0.0.1])\n\tby gate.crashing.org (8.14.1/8.13.8) with ESMTP id v8Q9j37E007613;\n\tTue, 26 Sep 2017 04:45:10 -0500"],"Message-ID":"<1506419102.2541.11.camel@kernel.crashing.org>","From":"Benjamin Herrenschmidt ","To":"David Gibson , =?iso-8859-1?q?C=E9dric?=\n\tLe Goater ","Date":"Tue, 26 Sep 2017 11:45:02 +0200","In-Reply-To":"<20170926035423.GH12504@umbus>","References":"<20170911171235.29331-1-clg@kaod.org>\n\t<20170911171235.29331-2-clg@kaod.org> <20170919022719.GH27153@umbus>\n\t\n\t<20170922110040.GP4998@umbus.fritz.box>\n\t\n\t<20170926035423.GH12504@umbus>","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.24.5 (3.24.5-1.fc26) ","Mime-Version":"1.0","Content-Transfer-Encoding":"7bit","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.6.x [fuzzy]","X-Received-From":"63.228.1.57","Subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Alexey Kardashevskiy , qemu-ppc@nongnu.org,\n\tqemu-devel@nongnu.org, Alexander Graf ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1805770,"web_url":"http://patchwork.ozlabs.org/comment/1805770/","msgid":"","list_archive_url":null,"date":"2017-11-16T15:58:53","subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","submitter":{"id":68548,"url":"http://patchwork.ozlabs.org/api/people/68548/","name":"Cédric Le Goater","email":"clg@kaod.org"},"content":"On 09/26/2017 05:54 AM, David Gibson wrote:\n> On Fri, Sep 22, 2017 at 02:42:07PM +0200, Cédric Le Goater wrote:\n>> On 09/22/2017 01:00 PM, David Gibson wrote:\n>>> On Tue, Sep 19, 2017 at 03:15:44PM +0200, Cédric Le Goater wrote:\n>>>> On 09/19/2017 04:27 AM, David Gibson wrote:\n>>>>> On Mon, Sep 11, 2017 at 07:12:15PM +0200, Cédric Le Goater wrote:\n>>>>>> Start with a couple of attributes for the XIVE sPAPR controller\n>>>>>> model. The number of provisionned IRQ is necessary to size the\n>>>>>> different internal XIVE tables, the number of CPUs is also.\n>>>>>>\n>>>>>> Signed-off-by: Cédric Le Goater \n>>>>>\n>>>>> [snip]\n>>>>>\n>>>>>> +static void spapr_xive_realize(DeviceState *dev, Error **errp)\n>>>>>> +{\n>>>>>> + sPAPRXive *xive = SPAPR_XIVE(dev);\n>>>>>> +\n>>>>>> + if (!xive->nr_targets) {\n>>>>>> + error_setg(errp, \"Number of interrupt targets needs to be greater 0\");\n>>>>>> + return;\n>>>>>> + }\n>>>>>> + /* We need to be able to allocate at least the IPIs */\n>>>>>> + if (!xive->nr_irqs || xive->nr_irqs < xive->nr_targets) {\n>>>>>> + error_setg(errp, \"Number of interrupts too small\");\n>>>>>> + return;\n>>>>>> + }\n>>>>>> +}\n>>>>>> +\n>>>>>> +static Property spapr_xive_properties[] = {\n>>>>>> + DEFINE_PROP_UINT32(\"nr-irqs\", sPAPRXive, nr_irqs, 0),\n>>>>>> + DEFINE_PROP_UINT32(\"nr-targets\", sPAPRXive, nr_targets, 0),\n>>>>>\n>>>>> I'm a bit uneasy about the number of targets having to be set in\n>>>>> advance: this can make life awkward when CPUs are hotplugged. I know\n>>>>> there's something similar in xics, but it has caused some hassles, and\n>>>>> we're starting to move away from it.\n>>>>>\n>>>>> Do you really need this?\n>>>>>\n>>>>\n>>>> Some of the internal table size depend on the number of cpus \n>>>> defined for the machine.\n>>>\n>>> Which ones? My impression was that there needed to be at least #cpus\n>>> * #priority-levels EQs, but there could be more than that, \n>>\n>> euh no, not in spapr mode at least. There are 8 queues per cpu.\n> \n> Ok.\n> \n>>> so it was no longer as tightly bound to the number if \"interrupt servers\"> as xics.\n>>\n>> ah. I think I see what you mean, that we could allocate them on the \n>> fly when needed by some hcalls ?\n> \n> Not at hcall time, no, but at cpu hot(un)plug time I was wondering if we\n> could (de)allocate them then.\n\nYes. I am currently reshuffling the ppc/xive patchset on top of the \nsPAPR allocator, also trying to take into account your comments and \nBen's. And I think we can do that. \n\nI have introduced a specific XiveICPState (stored under the ->intc\npointer of the CPUState) but I think we can go a little further and\nalso store the XiveEQ array there. So that all the state related to \na CPU would be allocated at init time or hot(un)plug time hot time.\n\nWe could call the resulting compound object (ICP + EQs) a sPAPRXiveCore \nor something like that. And we won't need to keep 'nr_targets' around \nthe sPAPR Xive object anymore *if* we do one more thing. See below. \n\n>> The other place where I use the nr_targets is to provision the \n>> IRQ numbers for the IPIs but that could probably be done in some \n>> other way, specially it there is a IRQ allocator at the machine\n>> level.\n> \n> Hm, ok.\n\nThe sPAPRXiveCore object above could also allocate the IPI for XIVE \nwhen it is created. But, the resulting IRQ number should be in a range \nnot overlapping with the other devices' IRQs. \n\nThat means that we should probably introduce the BUID concept in the \nIRQ allocator. This concept was left out from the original design of \nXICS as it was using a single ICS but it would be useful to define \nranges for devices now. for PHBs for instance.\n\nWe could start with 2K or 4K ranges. The first one would be for IPIs.\n\nDave, could you please take a quick look at the allocator patchset \nwhen you have some time. I don't think there is much to do in the API \nto introduce ranges. It is just a question of defining a 'start' value \nwhen looking for an empty slot. \n\nThanks,\n\nC. \n\n>>\n>> C. \n>>>> When the sPAPRXive object is instantiated, \n>>>> we use xics_max_server_number() to get the max number of cpus\n>>>> provisioned.\n>>>>\n>>>> C.\n>>>>\n>>>\n>>\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yd5Y00bg6z9s4q\n\tfor ;\n\tFri, 17 Nov 2017 02:59:48 +1100 (AEDT)","from localhost ([::1]:41520 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1eFMZu-0002oh-3a\n\tfor incoming@patchwork.ozlabs.org; Thu, 16 Nov 2017 10:59:46 -0500","from eggs.gnu.org ([2001:4830:134:3::10]:46532)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1eFMZK-0002oT-Lr\n\tfor qemu-devel@nongnu.org; Thu, 16 Nov 2017 10:59:11 -0500","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1eFMZG-0001n5-Mk\n\tfor qemu-devel@nongnu.org; Thu, 16 Nov 2017 10:59:10 -0500","from 8.mo68.mail-out.ovh.net ([46.105.74.219]:50422)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1eFMZG-0001jq-FM\n\tfor qemu-devel@nongnu.org; Thu, 16 Nov 2017 10:59:06 -0500","from player750.ha.ovh.net (b6.ovh.net [213.186.33.56])\n\tby mo68.mail-out.ovh.net (Postfix) with ESMTP id 439899D3EA\n\tfor ; Thu, 16 Nov 2017 16:59:03 +0100 (CET)","from zorba.kaod.org (LFbn-1-2231-173.w90-76.abo.wanadoo.fr\n\t[90.76.52.173]) (Authenticated sender: postmaster@kaod.org)\n\tby player750.ha.ovh.net (Postfix) with ESMTPSA id 848CE1800C2;\n\tThu, 16 Nov 2017 16:58:53 +0100 (CET)"],"To":"David Gibson ","References":"<20170911171235.29331-1-clg@kaod.org>\n\t<20170911171235.29331-2-clg@kaod.org> <20170919022719.GH27153@umbus>\n\t\n\t<20170922110040.GP4998@umbus.fritz.box>\n\t\n\t<20170926035423.GH12504@umbus>","From":"=?utf-8?q?C=C3=A9dric_Le_Goater?= ","Message-ID":"","Date":"Thu, 16 Nov 2017 16:58:53 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<20170926035423.GH12504@umbus>","Content-Type":"text/plain; charset=windows-1252","Content-Language":"en-US","X-Ovh-Tracer-Id":"13098438044502231928","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrgedttddrjeehgdekvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"46.105.74.219","Subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Alexey Kardashevskiy , qemu-ppc@nongnu.org,\n\tqemu-devel@nongnu.org, Alexander Graf ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1805816,"web_url":"http://patchwork.ozlabs.org/comment/1805816/","msgid":"","list_archive_url":null,"date":"2017-11-16T16:48:56","subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","submitter":{"id":68548,"url":"http://patchwork.ozlabs.org/api/people/68548/","name":"Cédric Le Goater","email":"clg@kaod.org"},"content":"On 09/26/2017 11:45 AM, Benjamin Herrenschmidt wrote:\n> On Tue, 2017-09-26 at 13:54 +1000, David Gibson wrote:\n>>>>\n>>>> Which ones? My impression was that there needed to be at least #cpus\n>>>> * #priority-levels EQs, but there could be more than that, \n>>>\n>>> euh no, not in spapr mode at least. There are 8 queues per cpu.\n>>\n>> Ok.\n> \n> There's a HW feature of XIVE in DD2.x that I will start exploiting soon\n> that sacrifices a queue btw, keep that in mind.\n> \n> We should probably only expose 0...6 to guests, not 0...7.\n\nyes. This is achieved using the \"ibm,plat-res-int-priorities\" property \nof the device tree. \n\nI don't think we also need to check these priority ranges when allocating\nthe EQs. We can just allocate them all (8 priorities) and let the hcalls \ndo the checks. They should return H_P3 or H_P4 if the prio is invalid.\n\nC.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yd6gG4rxrz9s0g\n\tfor ;\n\tFri, 17 Nov 2017 03:50:18 +1100 (AEDT)","from localhost ([::1]:41769 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1eFNMm-0005Qi-Qa\n\tfor incoming@patchwork.ozlabs.org; Thu, 16 Nov 2017 11:50:16 -0500","from eggs.gnu.org ([2001:4830:134:3::10]:37780)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1eFNLg-00051H-Lr\n\tfor qemu-devel@nongnu.org; Thu, 16 Nov 2017 11:49:14 -0500","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1eFNLc-0008W0-PJ\n\tfor qemu-devel@nongnu.org; Thu, 16 Nov 2017 11:49:08 -0500","from 10.mo68.mail-out.ovh.net ([46.105.79.203]:33268)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1eFNLc-0008VD-IF\n\tfor qemu-devel@nongnu.org; Thu, 16 Nov 2017 11:49:04 -0500","from player750.ha.ovh.net (b6.ovh.net [213.186.33.56])\n\tby mo68.mail-out.ovh.net (Postfix) with ESMTP id 0BD229DA71\n\tfor ; Thu, 16 Nov 2017 17:49:02 +0100 (CET)","from zorba.kaod.org (LFbn-1-2231-173.w90-76.abo.wanadoo.fr\n\t[90.76.52.173]) (Authenticated sender: postmaster@kaod.org)\n\tby player750.ha.ovh.net (Postfix) with ESMTPSA id 53F0D180098;\n\tThu, 16 Nov 2017 17:48:56 +0100 (CET)"],"To":"Benjamin Herrenschmidt ,\n\tDavid Gibson ","References":"<20170911171235.29331-1-clg@kaod.org>\n\t<20170911171235.29331-2-clg@kaod.org> <20170919022719.GH27153@umbus>\n\t\n\t<20170922110040.GP4998@umbus.fritz.box>\n\t\n\t<20170926035423.GH12504@umbus>\n\t<1506419102.2541.11.camel@kernel.crashing.org>","From":"=?utf-8?q?C=C3=A9dric_Le_Goater?= ","Message-ID":"","Date":"Thu, 16 Nov 2017 17:48:56 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<1506419102.2541.11.camel@kernel.crashing.org>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Ovh-Tracer-Id":"13942581499707296632","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrgedttddrjeehgdelfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"46.105.79.203","Subject":"Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a\n\tskeleton for the sPAPR XIVE interrupt controller","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Alexey Kardashevskiy , qemu-ppc@nongnu.org,\n\tqemu-devel@nongnu.org, Alexander Graf ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}}]