[{"id":1766600,"web_url":"http://patchwork.ozlabs.org/comment/1766600/","msgid":"<20170912000458.333f360f@bahia.lan>","list_archive_url":null,"date":"2017-09-11T22:04:58","subject":"Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH v2 04/21] ppc/xive: provide\n\ta link to the sPAPR ICS object under XIVE","submitter":{"id":69178,"url":"http://patchwork.ozlabs.org/api/people/69178/","name":"Greg Kurz","email":"groug@kaod.org"},"content":"On Mon, 11 Sep 2017 19:12:18 +0200\nCédric Le Goater wrote:\n\n> The sPAPR machine first starts with a XICS interrupt model and\n> depending on the guest capabilities, the XIVE exploitation mode is\n> negotiated during CAS. A reset should then be performed to rebuild the\n> device tree but the same IRQ numbers which were allocated by the\n> devices prior to reset, when the XICS model was operating, are still\n> in use.\n> \n> For this purpose, we need a common IRQ number allocator for both the\n> interrupt models: XICS legacy or XIVE exploitation. This is what the\n> ICSIRQState array of the XICS interrupt source is used for. It also\n> contains the LSI/MSI flag of an interrupt which will we need later on.\n> \n> So, let's provide a link to the sPAPR ICS object under XIVE to make\n> use of it.\n> \n> Signed-off-by: Cédric Le Goater \n> ---\n> hw/intc/spapr_xive.c | 12 ++++++++++++\n> include/hw/ppc/spapr_xive.h | 4 ++++\n> 2 files changed, 16 insertions(+)\n> \n> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c\n> index 6d98528fae68..1681affb0848 100644\n> --- a/hw/intc/spapr_xive.c\n> +++ b/hw/intc/spapr_xive.c\n> @@ -56,6 +56,8 @@ void spapr_xive_reset(void *dev)\n> static void spapr_xive_realize(DeviceState *dev, Error **errp)\n> {\n> sPAPRXive *xive = SPAPR_XIVE(dev);\n> + Object *obj;\n> + Error *err = NULL;\n> \n> if (!xive->nr_targets) {\n> error_setg(errp, \"Number of interrupt targets needs to be greater 0\");\n> @@ -68,6 +70,16 @@ static void spapr_xive_realize(DeviceState *dev, Error **errp)\n> return;\n> }\n> \n> + /* Retrieve SPAPR ICS source to share the IRQ number allocator */\n> + obj = object_property_get_link(OBJECT(dev), \"ics\", &err);\n> + if (!obj) {\n> + error_setg(errp, \"%s: required link 'ics' not found: %s\",\n> + __func__, error_get_pretty(err));\n> + return;\n\nerr is leaked if you do this way. Please do this instead:\n\n error_propagate(errp, err);\n error_prepend(errp, \"required link 'ics' not found: \");\n\nNote: I've just sent a patch to fix the same error in XICS :)\n\n> + }\n> +\n> + xive->ics = ICS_BASE(obj);\n> +\n> /* Allocate SBEs (State Bit Entry). 2 bits, so 4 entries per byte */\n> xive->sbe_size = DIV_ROUND_UP(xive->nr_irqs, 4);\n> xive->sbe = g_malloc0(xive->sbe_size);\n> diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h\n> index b17dd4f17b0b..29112589b37f 100644\n> --- a/include/hw/ppc/spapr_xive.h\n> +++ b/include/hw/ppc/spapr_xive.h\n> @@ -24,6 +24,7 @@\n> typedef struct sPAPRXive sPAPRXive;\n> typedef struct XiveIVE XiveIVE;\n> typedef struct XiveEQ XiveEQ;\n> +typedef struct ICSState ICSState;\n> \n> #define TYPE_SPAPR_XIVE \"spapr-xive\"\n> #define SPAPR_XIVE(obj) OBJECT_CHECK(sPAPRXive, (obj), TYPE_SPAPR_XIVE)\n> @@ -35,6 +36,9 @@ struct sPAPRXive {\n> uint32_t nr_targets;\n> uint32_t nr_irqs;\n> \n> + /* IRQ */\n> + ICSState *ics; /* XICS source inherited from the SPAPR machine */\n> +\n> /* XIVE internal tables */\n> uint8_t *sbe;\n> uint32_t sbe_size;","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 3xrhnn50Vpz9s7C\n\tfor ;\n\tTue, 12 Sep 2017 08:05:49 +1000 (AEST)","from localhost ([::1]:60821 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1drWpv-0008HP-Py\n\tfor incoming@patchwork.ozlabs.org; Mon, 11 Sep 2017 18:05:47 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:53386)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1drWpM-0008EG-Lg\n\tfor qemu-devel@nongnu.org; Mon, 11 Sep 2017 18:05:13 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1drWpI-0006Q1-Ik\n\tfor qemu-devel@nongnu.org; Mon, 11 Sep 2017 18:05:12 -0400","from 20.mo1.mail-out.ovh.net ([188.165.45.168]:59146)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1drWpI-0006OH-CK\n\tfor qemu-devel@nongnu.org; Mon, 11 Sep 2017 18:05:08 -0400","from player169.ha.ovh.net (b9.ovh.net [213.186.33.59])\n\tby mo1.mail-out.ovh.net (Postfix) with ESMTP id EBB1E917E5\n\tfor ; Tue, 12 Sep 2017 00:05:06 +0200 (CEST)","from bahia.lan (gar31-1-82-66-74-139.fbx.proxad.net [82.66.74.139])\n\t(Authenticated sender: groug@kaod.org)\n\tby player169.ha.ovh.net (Postfix) with ESMTPSA id 09B3C580082;\n\tTue, 12 Sep 2017 00:04:59 +0200 (CEST)"],"Date":"Tue, 12 Sep 2017 00:04:58 +0200","From":"Greg Kurz ","To":"=?utf-8?q?C=C3=A9dric?= Le Goater ","Message-ID":"<20170912000458.333f360f@bahia.lan>","In-Reply-To":"<20170911171235.29331-5-clg@kaod.org>","References":"<20170911171235.29331-1-clg@kaod.org>\n\t<20170911171235.29331-5-clg@kaod.org>","X-Mailer":"Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu)","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tboundary=\"Sig_/s6oiuobUCTOpFH2ENgkFFIv\";\n\tprotocol=\"application/pgp-signature\"","X-Ovh-Tracer-Id":"617556099959265675","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrfeelledrgedtgddujeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"188.165.45.168","Subject":"Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH v2 04/21] ppc/xive: provide\n\ta link to the sPAPR ICS object under XIVE","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 , Alexander Graf ,\n\tqemu-devel@nongnu.org, qemu-ppc@nongnu.org,\n\tDavid Gibson ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1766691,"web_url":"http://patchwork.ozlabs.org/comment/1766691/","msgid":"<805a49ef-e7ab-b8bc-c992-9982f06e375a@kaod.org>","list_archive_url":null,"date":"2017-09-12T05:47:23","subject":"Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH v2 04/21] ppc/xive: provide\n\ta link to the sPAPR ICS object under XIVE","submitter":{"id":68548,"url":"http://patchwork.ozlabs.org/api/people/68548/","name":"Cédric Le Goater","email":"clg@kaod.org"},"content":"On 09/12/2017 12:04 AM, Greg Kurz wrote:\n> On Mon, 11 Sep 2017 19:12:18 +0200\n> Cédric Le Goater wrote:\n> \n>> The sPAPR machine first starts with a XICS interrupt model and\n>> depending on the guest capabilities, the XIVE exploitation mode is\n>> negotiated during CAS. A reset should then be performed to rebuild the\n>> device tree but the same IRQ numbers which were allocated by the\n>> devices prior to reset, when the XICS model was operating, are still\n>> in use.\n>>\n>> For this purpose, we need a common IRQ number allocator for both the\n>> interrupt models: XICS legacy or XIVE exploitation. This is what the\n>> ICSIRQState array of the XICS interrupt source is used for. It also\n>> contains the LSI/MSI flag of an interrupt which will we need later on.\n>>\n>> So, let's provide a link to the sPAPR ICS object under XIVE to make\n>> use of it.\n>>\n>> Signed-off-by: Cédric Le Goater \n>> ---\n>> hw/intc/spapr_xive.c | 12 ++++++++++++\n>> include/hw/ppc/spapr_xive.h | 4 ++++\n>> 2 files changed, 16 insertions(+)\n>>\n>> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c\n>> index 6d98528fae68..1681affb0848 100644\n>> --- a/hw/intc/spapr_xive.c\n>> +++ b/hw/intc/spapr_xive.c\n>> @@ -56,6 +56,8 @@ void spapr_xive_reset(void *dev)\n>> static void spapr_xive_realize(DeviceState *dev, Error **errp)\n>> {\n>> sPAPRXive *xive = SPAPR_XIVE(dev);\n>> + Object *obj;\n>> + Error *err = NULL;\n>> \n>> if (!xive->nr_targets) {\n>> error_setg(errp, \"Number of interrupt targets needs to be greater 0\");\n>> @@ -68,6 +70,16 @@ static void spapr_xive_realize(DeviceState *dev, Error **errp)\n>> return;\n>> }\n>> \n>> + /* Retrieve SPAPR ICS source to share the IRQ number allocator */\n>> + obj = object_property_get_link(OBJECT(dev), \"ics\", &err);\n>> + if (!obj) {\n>> + error_setg(errp, \"%s: required link 'ics' not found: %s\",\n>> + __func__, error_get_pretty(err));\n>> + return;\n> \n> err is leaked if you do this way. Please do this instead:\n> \n> error_propagate(errp, err);\n> error_prepend(errp, \"required link 'ics' not found: \");\n\nok. I will fix. \n\nC.\n\n> Note: I've just sent a patch to fix the same error in XICS :)\n>\n>> + }\n>> +\n>> + xive->ics = ICS_BASE(obj);\n>> +\n>> /* Allocate SBEs (State Bit Entry). 2 bits, so 4 entries per byte */\n>> xive->sbe_size = DIV_ROUND_UP(xive->nr_irqs, 4);\n>> xive->sbe = g_malloc0(xive->sbe_size);\n>> diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h\n>> index b17dd4f17b0b..29112589b37f 100644\n>> --- a/include/hw/ppc/spapr_xive.h\n>> +++ b/include/hw/ppc/spapr_xive.h\n>> @@ -24,6 +24,7 @@\n>> typedef struct sPAPRXive sPAPRXive;\n>> typedef struct XiveIVE XiveIVE;\n>> typedef struct XiveEQ XiveEQ;\n>> +typedef struct ICSState ICSState;\n>> \n>> #define TYPE_SPAPR_XIVE \"spapr-xive\"\n>> #define SPAPR_XIVE(obj) OBJECT_CHECK(sPAPRXive, (obj), TYPE_SPAPR_XIVE)\n>> @@ -35,6 +36,9 @@ struct sPAPRXive {\n>> uint32_t nr_targets;\n>> uint32_t nr_irqs;\n>> \n>> + /* IRQ */\n>> + ICSState *ics; /* XICS source inherited from the SPAPR machine */\n>> +\n>> /* XIVE internal tables */\n>> uint8_t *sbe;\n>> uint32_t sbe_size;\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 3xrv3S1JJrz9s7g\n\tfor ;\n\tTue, 12 Sep 2017 15:48:20 +1000 (AEST)","from localhost ([::1]:33736 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dre3W-0000HU-7l\n\tfor incoming@patchwork.ozlabs.org; Tue, 12 Sep 2017 01:48:18 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:49999)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dre30-0000Co-Sg\n\tfor qemu-devel@nongnu.org; Tue, 12 Sep 2017 01:47:48 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dre2x-00014f-PM\n\tfor qemu-devel@nongnu.org; Tue, 12 Sep 2017 01:47:46 -0400","from 8.mo2.mail-out.ovh.net ([188.165.52.147]:38279)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dre2x-0000wZ-KL\n\tfor qemu-devel@nongnu.org; Tue, 12 Sep 2017 01:47:43 -0400","from player770.ha.ovh.net (b6.ovh.net [213.186.33.56])\n\tby mo2.mail-out.ovh.net (Postfix) with ESMTP id C28AEAB054\n\tfor ; Tue, 12 Sep 2017 07:47:32 +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 player770.ha.ovh.net (Postfix) with ESMTPSA id 8D66C3C006A;\n\tTue, 12 Sep 2017 07:47:23 +0200 (CEST)"],"To":"Greg Kurz ","References":"<20170911171235.29331-1-clg@kaod.org>\n\t<20170911171235.29331-5-clg@kaod.org>\n\t<20170912000458.333f360f@bahia.lan>","From":"=?utf-8?q?C=C3=A9dric_Le_Goater?= ","Message-ID":"<805a49ef-e7ab-b8bc-c992-9982f06e375a@kaod.org>","Date":"Tue, 12 Sep 2017 07:47:23 +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":"<20170912000458.333f360f@bahia.lan>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","X-Ovh-Tracer-Id":"8427360804541401976","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrfeelledrgedugdehlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd","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":"188.165.52.147","Subject":"Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH v2 04/21] ppc/xive: provide\n\ta link to the sPAPR ICS object under XIVE","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 , Alexander Graf ,\n\tqemu-devel@nongnu.org, qemu-ppc@nongnu.org,\n\tDavid Gibson ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1770870,"web_url":"http://patchwork.ozlabs.org/comment/1770870/","msgid":"<20170919024417.GJ27153@umbus>","list_archive_url":null,"date":"2017-09-19T02:44:17","subject":"Re: [Qemu-devel] [RFC PATCH v2 04/21] ppc/xive: provide a link to\n\tthe sPAPR ICS object under XIVE","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:18PM +0200, Cédric Le Goater wrote:\n> The sPAPR machine first starts with a XICS interrupt model and\n> depending on the guest capabilities, the XIVE exploitation mode is\n> negotiated during CAS. A reset should then be performed to rebuild the\n> device tree but the same IRQ numbers which were allocated by the\n> devices prior to reset, when the XICS model was operating, are still\n> in use.\n> \n> For this purpose, we need a common IRQ number allocator for both the\n> interrupt models: XICS legacy or XIVE exploitation. This is what the\n> ICSIRQState array of the XICS interrupt source is used for. It also\n> contains the LSI/MSI flag of an interrupt which will we need later on.\n> \n> So, let's provide a link to the sPAPR ICS object under XIVE to make\n> use of it.\n\nBlech, please don't. The XIVE code absolutely shouldn't be\nreferencing XICS objects, it's a recipe for trouble down the line.\n\nIf we have to have some sort of abstract \"spapr interrupt source\"\nobject that could map to either an ICS irq, or a XIVE source then we\ncan do that, but don't directly link XIVE and XICS. *Especially* not\nnew-in-terms-of-old like this, rather than old-in-terms-of-new.\n\n\n> \n> Signed-off-by: Cédric Le Goater \n> ---\n> hw/intc/spapr_xive.c | 12 ++++++++++++\n> include/hw/ppc/spapr_xive.h | 4 ++++\n> 2 files changed, 16 insertions(+)\n> \n> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c\n> index 6d98528fae68..1681affb0848 100644\n> --- a/hw/intc/spapr_xive.c\n> +++ b/hw/intc/spapr_xive.c\n> @@ -56,6 +56,8 @@ void spapr_xive_reset(void *dev)\n> static void spapr_xive_realize(DeviceState *dev, Error **errp)\n> {\n> sPAPRXive *xive = SPAPR_XIVE(dev);\n> + Object *obj;\n> + Error *err = NULL;\n> \n> if (!xive->nr_targets) {\n> error_setg(errp, \"Number of interrupt targets needs to be greater 0\");\n> @@ -68,6 +70,16 @@ static void spapr_xive_realize(DeviceState *dev, Error **errp)\n> return;\n> }\n> \n> + /* Retrieve SPAPR ICS source to share the IRQ number allocator */\n\nThis really suggests we need to move the irq number allocator out of\nXICS and into the general spapr code. Or get rid of it entirely\n(using a more static irq mapping) if possible.\n\n> + obj = object_property_get_link(OBJECT(dev), \"ics\", &err);\n> + if (!obj) {\n> + error_setg(errp, \"%s: required link 'ics' not found: %s\",\n> + __func__, error_get_pretty(err));\n> + return;\n> + }\n> +\n> + xive->ics = ICS_BASE(obj);\n> +\n> /* Allocate SBEs (State Bit Entry). 2 bits, so 4 entries per byte */\n> xive->sbe_size = DIV_ROUND_UP(xive->nr_irqs, 4);\n> xive->sbe = g_malloc0(xive->sbe_size);\n> diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h\n> index b17dd4f17b0b..29112589b37f 100644\n> --- a/include/hw/ppc/spapr_xive.h\n> +++ b/include/hw/ppc/spapr_xive.h\n> @@ -24,6 +24,7 @@\n> typedef struct sPAPRXive sPAPRXive;\n> typedef struct XiveIVE XiveIVE;\n> typedef struct XiveEQ XiveEQ;\n> +typedef struct ICSState ICSState;\n> \n> #define TYPE_SPAPR_XIVE \"spapr-xive\"\n> #define SPAPR_XIVE(obj) OBJECT_CHECK(sPAPRXive, (obj), TYPE_SPAPR_XIVE)\n> @@ -35,6 +36,9 @@ struct sPAPRXive {\n> uint32_t nr_targets;\n> uint32_t nr_irqs;\n> \n> + /* IRQ */\n> + ICSState *ics; /* XICS source inherited from the SPAPR machine */\n> +\n> /* XIVE internal tables */\n> uint8_t *sbe;\n> uint32_t sbe_size;","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=\"l6DtbVCQ\"; \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 3xxKlD2p2nz9rxj\n\tfor ;\n\tTue, 19 Sep 2017 21:04:40 +1000 (AEST)","from localhost ([::1]:41527 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duGKU-0007BQ-Dg\n\tfor incoming@patchwork.ozlabs.org; Tue, 19 Sep 2017 07:04:38 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:51334)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duFta-0001J9-RS\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 06:36:54 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duFtX-0002ye-5v\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 06:36:50 -0400","from ozlabs.org ([103.22.144.67]:34673)\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 1duFtW-0002tA-Js; Tue, 19 Sep 2017 06:36:47 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xxK6q6fsFz9t3t; 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=1505817395;\n\tbh=V1Age9I6bns76nyPrO+JIJwlSYoiI3lXpIU3aYcQxFQ=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=l6DtbVCQCg3zUEFN6Ww/d3ppK5QcIn04vEj+Jz478Ea0+NL+h5NtP2I9l12LwWP8U\n\ttE4sozThBzWh28OwB551RRDiIVVwFc1v6uQG21BxY8IXc8t4wWZxjZDGWMC72s0cTr\n\tSihxaS1IUfaELem/rHJtBgGLOgAb+BESSdPa3NaE=","Date":"Tue, 19 Sep 2017 12:44:17 +1000","From":"David Gibson ","To":"=?iso-8859-1?q?C=E9dric?= Le Goater ","Message-ID":"<20170919024417.GJ27153@umbus>","References":"<20170911171235.29331-1-clg@kaod.org>\n\t<20170911171235.29331-5-clg@kaod.org>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"3CAnR4CLEnEWqRMR\"","Content-Disposition":"inline","In-Reply-To":"<20170911171235.29331-5-clg@kaod.org>","User-Agent":"Mutt/1.8.3 (2017-05-23)","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 04/21] ppc/xive: provide a link to\n\tthe sPAPR ICS object under XIVE","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":1771109,"web_url":"http://patchwork.ozlabs.org/comment/1771109/","msgid":"<3ce4302f-87ec-9720-1adf-8a86b4d9b6d2@kaod.org>","list_archive_url":null,"date":"2017-09-19T14:46:02","subject":"Re: [Qemu-devel] [RFC PATCH v2 04/21] ppc/xive: provide a link to\n\tthe sPAPR ICS object under XIVE","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:44 AM, David Gibson wrote:\n> On Mon, Sep 11, 2017 at 07:12:18PM +0200, Cédric Le Goater wrote:\n>> The sPAPR machine first starts with a XICS interrupt model and\n>> depending on the guest capabilities, the XIVE exploitation mode is\n>> negotiated during CAS. A reset should then be performed to rebuild the\n>> device tree but the same IRQ numbers which were allocated by the\n>> devices prior to reset, when the XICS model was operating, are still\n>> in use.\n>>\n>> For this purpose, we need a common IRQ number allocator for both the\n>> interrupt models: XICS legacy or XIVE exploitation. This is what the\n>> ICSIRQState array of the XICS interrupt source is used for. It also\n>> contains the LSI/MSI flag of an interrupt which will we need later on.\n>>\n>> So, let's provide a link to the sPAPR ICS object under XIVE to make\n>> use of it.\n> \n> Blech, please don't. The XIVE code absolutely shouldn't be\n> referencing XICS objects, it's a recipe for trouble down the line.\n\nTrouble I don't know. But it is a bit ugly and this is why this \npatchset is still an RFC. \n\n> If we have to have some sort of abstract \"spapr interrupt source\"\n> object that could map to either an ICS irq, or a XIVE source then we\n> can do that, but don't directly link XIVE and XICS. *Especially* not\n> new-in-terms-of-old like this, rather than old-in-terms-of-new.\n\nI agree with what you are saying on a common interrupt source but \nI just haven't found a way to do so yet. So I am trying to corner \nthe ugliness in obvious shortcuts. The purpose is to identify what\nwe need to support migration, hotplug, cas reset, etc.\n\nSo the current solution is practical to support CAS reset and more \nimportant it does not break migration. We can't move an object or \nparts of an object around without breaking the migration as my \nrecent changes on the xics icp have shown. \n\n>>\n>> Signed-off-by: Cédric Le Goater \n>> ---\n>> hw/intc/spapr_xive.c | 12 ++++++++++++\n>> include/hw/ppc/spapr_xive.h | 4 ++++\n>> 2 files changed, 16 insertions(+)\n>>\n>> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c\n>> index 6d98528fae68..1681affb0848 100644\n>> --- a/hw/intc/spapr_xive.c\n>> +++ b/hw/intc/spapr_xive.c\n>> @@ -56,6 +56,8 @@ void spapr_xive_reset(void *dev)\n>> static void spapr_xive_realize(DeviceState *dev, Error **errp)\n>> {\n>> sPAPRXive *xive = SPAPR_XIVE(dev);\n>> + Object *obj;\n>> + Error *err = NULL;\n>> \n>> if (!xive->nr_targets) {\n>> error_setg(errp, \"Number of interrupt targets needs to be greater 0\");\n>> @@ -68,6 +70,16 @@ static void spapr_xive_realize(DeviceState *dev, Error **errp)\n>> return;\n>> }\n>> \n>> + /* Retrieve SPAPR ICS source to share the IRQ number allocator */\n> \n> This really suggests we need to move the irq number allocator out of\n> XICS and into the general spapr code. Or get rid of it entirely\n> (using a more static irq mapping) if possible.\n\nI have some out of tree changes introducing a bitmap at the spapr\nmachine level. It is a nice cleanup of the spapr_ics_free() and \nspapr_ics_alloc*() routines. But it is not migration friendly and \nwe still need to keep the ICSIRQState array, which also stores the \nIRQ state LSI/MSI. I need to check if such a change would bring\nsome benefits for XIVE.\n\nC.\n\n>> + obj = object_property_get_link(OBJECT(dev), \"ics\", &err);\n>> + if (!obj) {\n>> + error_setg(errp, \"%s: required link 'ics' not found: %s\",\n>> + __func__, error_get_pretty(err));\n>> + return;\n>> + }\n>> +\n>> + xive->ics = ICS_BASE(obj);\n>> +\n>> /* Allocate SBEs (State Bit Entry). 2 bits, so 4 entries per byte */\n>> xive->sbe_size = DIV_ROUND_UP(xive->nr_irqs, 4);\n>> xive->sbe = g_malloc0(xive->sbe_size);\n>> diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h\n>> index b17dd4f17b0b..29112589b37f 100644\n>> --- a/include/hw/ppc/spapr_xive.h\n>> +++ b/include/hw/ppc/spapr_xive.h\n>> @@ -24,6 +24,7 @@\n>> typedef struct sPAPRXive sPAPRXive;\n>> typedef struct XiveIVE XiveIVE;\n>> typedef struct XiveEQ XiveEQ;\n>> +typedef struct ICSState ICSState;\n>> \n>> #define TYPE_SPAPR_XIVE \"spapr-xive\"\n>> #define SPAPR_XIVE(obj) OBJECT_CHECK(sPAPRXive, (obj), TYPE_SPAPR_XIVE)\n>> @@ -35,6 +36,9 @@ struct sPAPRXive {\n>> uint32_t nr_targets;\n>> uint32_t nr_irqs;\n>> \n>> + /* IRQ */\n>> + ICSState *ics; /* XICS source inherited from the SPAPR machine */\n>> +\n>> /* XIVE internal tables */\n>> uint8_t *sbe;\n>> uint32_t sbe_size;\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 3xxQkN0Wcfz9sBZ\n\tfor ;\n\tWed, 20 Sep 2017 00:49:16 +1000 (AEST)","from localhost ([::1]:43332 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duJpq-0004j2-6O\n\tfor incoming@patchwork.ozlabs.org; Tue, 19 Sep 2017 10:49:14 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:36812)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duJn1-0002zP-1k\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 10:46:20 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duJmw-0000Ii-Pk\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 10:46:19 -0400","from 20.mo3.mail-out.ovh.net ([178.33.47.94]:40862)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1duJmw-0000Gs-GN\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 10:46:14 -0400","from player797.ha.ovh.net (b9.ovh.net [213.186.33.59])\n\tby mo3.mail-out.ovh.net (Postfix) with ESMTP id 5C4881518EB\n\tfor ; Tue, 19 Sep 2017 16:46:11 +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 6E9122E008A;\n\tTue, 19 Sep 2017 16:46:03 +0200 (CEST)"],"To":"David Gibson ","References":"<20170911171235.29331-1-clg@kaod.org>\n\t<20170911171235.29331-5-clg@kaod.org> <20170919024417.GJ27153@umbus>","From":"=?utf-8?q?C=C3=A9dric_Le_Goater?= ","Message-ID":"<3ce4302f-87ec-9720-1adf-8a86b4d9b6d2@kaod.org>","Date":"Tue, 19 Sep 2017 16:46:02 +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":"<20170919024417.GJ27153@umbus>","Content-Type":"text/plain; charset=windows-1252","Content-Language":"en-US","X-Ovh-Tracer-Id":"3292975753244740472","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrfeelledrheejgdekvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd","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.47.94","Subject":"Re: [Qemu-devel] [RFC PATCH v2 04/21] ppc/xive: provide a link to\n\tthe sPAPR ICS object under XIVE","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"}}]