[{"id":1778793,"web_url":"http://patchwork.ozlabs.org/comment/1778793/","msgid":"<4d649456-1242-febe-06bd-35bb01e3982b@ozlabs.ru>","list_archive_url":null,"date":"2017-10-03T09:12:29","subject":"Re: [Qemu-devel] [Qemu-ppc] [PATCH v5 1/6] ppc: spapr: Register and\n\thandle HCALL to receive updated RTAS region","submitter":{"id":7621,"url":"http://patchwork.ozlabs.org/api/people/7621/","name":"Alexey Kardashevskiy","email":"aik@ozlabs.ru"},"content":"On 03/10/17 17:07, David Gibson wrote:\n> On Mon, Oct 02, 2017 at 02:02:19PM +1100, Alexey Kardashevskiy wrote:\n>> On 29/09/17 21:52, Nikunj A Dadhania wrote:\n>>> David Gibson writes:\n>>>\n>>>> On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:\n>>>>> Receive updates from SLOF about the updated rtas-base.\n>>>>> A separate patch for SLOF [1] (commit f9a60de3) adds\n>>>>> functionality to invoke a private HCALL whenever OS\n>>>>> issues instantiate-rtas with a new rtas-base.\n>>>>>\n>>>>> This is required as QEMU needs to know the updated rtas-base\n>>>>> as it allocates error reporting structure in RTAS space upon\n>>>>> a machine check exception.\n>>>>>\n>>>>> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html\n>>>>>\n>>>>> Signed-off-by: Aravinda Prasad \n>>>>> Reviewed-by: David Gibson \n>>>>\n>>>> Ao I acked this earlier, but I've now realized there might be some\n>>>> connection between this and discussions taking place elsewhere about\n>>>> qemu not knowing what SLOF does with the device tree.\n>>>>\n>>>> At what point will SLOF call the UPDATE_RTAS hcall? I'm guessing at\n>>>> the time of instantiate-rtas, is that right?\n>>>\n>>> The call happens from\n>>> arch/powerpc/kernel/prom_init.c:prom_instantiate_rtas() and after that\n>>> linux kernel makes two entries in the DT\n>>>\n>>> ....\n>>> if (call_prom_ret(\"call-method\", 3, 2, &entry,\n>>> ADDR(\"instantiate-rtas\"),\n>>> rtas_inst, base) != 0\n>>> || entry == 0) {\n>>> prom_printf(\" failed\\n\");\n>>> return;\n>>> }\n>>> prom_printf(\" done\\n\");\n>>>\n>>> reserve_mem(base, size);\n>>>\n>>> val = cpu_to_be32(base);\n>>> prom_setprop(rtas_node, \"/rtas\", \"linux,rtas-base\",\n>>> &val, sizeof(val));\n>>> val = cpu_to_be32(entry);\n>>> prom_setprop(rtas_node, \"/rtas\", \"linux,rtas-entry\",\n>>> &val, sizeof(val));\n>>> ....\n>>>\n>>> Quiesce is called after this. \n>>>\n>>>> Does SLOF put the RTAS blob address in its internal device tree, or\n>>>> does it only pass it to the guest via the return parameters from\n>>>> instantiate-rtas?\n>>>\n>>> Entry was made to the DT by linux kernel prom_init code, will this be\n>>> visible to QEMU?\n>>\n>> With my recent SLOF FDT patch - yes:\n>>\n>> aik@fstn1-p1:~$ grep rtas dbg.dts\n>> \trtas {\n>> \t\tlinux,rtas-entry = <0x2fff0000>;\n>> \t\tlinux,rtas-base = <0x2fff0000>;\n>> [...]\n> \n> Ah.. except.. isn't that relying on the kernel putting the RTAS\n> address into the device tree before it calls quiesce and kills SLOF?\n> \n> The SLOF image is bundled in with qemu, so it's ok for us to rely on\n> its behaviour up to a point. It's not really ok for us to rely on the\n> kernel's behaviour here, unless that behaviour is mandated by PAPR,\n> which this isn't.\n\nFair point.\n\n> So, I think we either need to have *SLOF* update the device tree with\n> that address at instantiate-rtas time,\n\nI can do that, in a separate patch.\n\n> or we'll need to resurrect\n> Aravinda's original UPDATE_RTAS hcall.","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\" (2048-bit key;\n\tunprotected) header.d=ozlabs-ru.20150623.gappssmtp.com\n\theader.i=@ozlabs-ru.20150623.gappssmtp.com\n\theader.b=\"tzeaVc8p\"; dkim-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 3y5tcF2snSz9t2c\n\tfor ;\n\tTue, 3 Oct 2017 20:13:17 +1100 (AEDT)","from localhost ([::1]:57238 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dzJGN-0002qA-FF\n\tfor incoming@patchwork.ozlabs.org; Tue, 03 Oct 2017 05:13:15 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:36586)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dzJFo-0002py-AN\n\tfor qemu-devel@nongnu.org; Tue, 03 Oct 2017 05:12:46 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dzJFk-0007Bm-B0\n\tfor qemu-devel@nongnu.org; Tue, 03 Oct 2017 05:12:40 -0400","from mail-it0-x243.google.com ([2607:f8b0:4001:c0b::243]:49262)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)\n\t(Exim 4.71) (envelope-from ) id 1dzJFk-00079j-1p\n\tfor qemu-devel@nongnu.org; Tue, 03 Oct 2017 05:12:36 -0400","by mail-it0-x243.google.com with SMTP id c195so10871110itb.4\n\tfor ; Tue, 03 Oct 2017 02:12:35 -0700 (PDT)","from [10.61.2.175] ([122.99.82.10])\n\tby smtp.googlemail.com with ESMTPSA id\n\te98sm5773642ioi.35.2017.10.03.02.12.30\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 03 Oct 2017 02:12:34 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ozlabs-ru.20150623.gappssmtp.com; s=20150623;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to;\n\tbh=PHAlYttgQhcoGRqNungmlRFcJddmC2YkjFvyh4XsZho=;\n\tb=tzeaVc8pMJxKy2FpP0BgN8bh2X+bzxDHEFCd/3OC+5Ji8HR5w+Mc44Pdv+1Plocg9T\n\t08jHtjAx979FvUwZNOEa+fZR4VjuR/9DN7Re8btwib3CsD5jTYlgvhUnezb5bUDon5Yq\n\tW4u8t8lrg73yF/OKbaEjNrQGDPtQswT86J+gtPv3CG1m3SmPt6O3IHd1gS8OEh83eldm\n\tB0+xfF4lyC0UTyTtQ0SLdDqfIsylFUYxXp/pyC59prWwtH/J2Xd1qvSZDBJXt1r/DxBV\n\t+pwCqHPgkTPON/HHaNvZav6QCr9PWYwcxAyn15uPNfaYhD6CGQ24DeS6HNUuaOi2gdHU\n\tv2yQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to;\n\tbh=PHAlYttgQhcoGRqNungmlRFcJddmC2YkjFvyh4XsZho=;\n\tb=iRiwqQxE8ojOIYrmCAdujvK1H6Y9A++OmIbWNGhEhHB9QhT/SeRgBtQwvio5wyWkF3\n\t72UKdK297c5ICjpozvG3Q6YXtgI5/CNeJq0OGVkcubasDqsfS/bZYYklwWA2SYGeK+Rp\n\t2osfZG44igymOv/lIayeVVLLeUYdSvGqERKzF+nCFflqfPR/3s04dfV/1WnBfuGr3apf\n\tXr9Cy0gN0kger8xQz57YfET2RGz8rNSqX8ewQfRUDPbWOKj7TRh6oTUHfAjUZhw5A0nz\n\tyl5OxRFCIztqFlQ5DoOdGQpPDR+e08Puk8rzlXrUazr4cCgVdwX2bDF3dfeIkB2gtAbE\n\tjq5A==","X-Gm-Message-State":"AHPjjUjMMo+apnG0m+vz6IA6TvUMtlPNs4wx6pz3NFtSNtIRW9yT0I0U\n\tg6kv7Sxc+XwWBZdZ+EwUYInxxA==","X-Google-Smtp-Source":"AOwi7QAkw7zTN6MlNi9pQOCuZYcxRJqBdYdD5kGotwCbChv7JaFphs7MHz2bbWopOBEIfHqU7WKbgg==","X-Received":"by 10.36.11.8 with SMTP id 8mr22073472itd.94.1507021955014;\n\tTue, 03 Oct 2017 02:12:35 -0700 (PDT)","To":"David Gibson ","References":"<150659494872.25889.2069124544245723984.stgit@aravinda>\n\t<150659505839.25889.2018054058894535368.stgit@aravinda>\n\t<20170929061735.GD7712@umbus.fritz.box>\n\t<87y3oxen7t.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<95142cc0-518a-b7b7-4e56-cfc2adca36ba@ozlabs.ru>\n\t<20171003060757.GF3260@umbus.fritz.box>","From":"Alexey Kardashevskiy ","Message-ID":"<4d649456-1242-febe-06bd-35bb01e3982b@ozlabs.ru>","Date":"Tue, 3 Oct 2017 20:12:29 +1100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20171003060757.GF3260@umbus.fritz.box>","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"SV3pWiEt0n2tRjpMpvAuGTW5cTBenQPOJ\"","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2607:f8b0:4001:c0b::243","X-Content-Filtered-By":"Mailman/MimeDel 2.1.21","Subject":"Re: [Qemu-devel] [Qemu-ppc] [PATCH v5 1/6] ppc: spapr: Register and\n\thandle HCALL to receive updated RTAS region","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":"benh@au1.ibm.com, Nikunj A Dadhania ,\n\tqemu-devel@nongnu.org, qemu-ppc@nongnu.org, sam.bobroff@au1.ibm.com, \n\tAravinda Prasad , paulus@samba.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1779386,"web_url":"http://patchwork.ozlabs.org/comment/1779386/","msgid":"<8fa746ca-302f-b2bf-ee05-a4b0b4f2fcbb@ozlabs.ru>","list_archive_url":null,"date":"2017-10-04T03:32:11","subject":"Re: [Qemu-devel] [Qemu-ppc] [PATCH v5 1/6] ppc: spapr: Register and\n\thandle HCALL to receive updated RTAS region","submitter":{"id":7621,"url":"http://patchwork.ozlabs.org/api/people/7621/","name":"Alexey Kardashevskiy","email":"aik@ozlabs.ru"},"content":"On 03/10/17 20:12, Alexey Kardashevskiy wrote:\n> On 03/10/17 17:07, David Gibson wrote:\n>> On Mon, Oct 02, 2017 at 02:02:19PM +1100, Alexey Kardashevskiy wrote:\n>>> On 29/09/17 21:52, Nikunj A Dadhania wrote:\n>>>> David Gibson writes:\n>>>>\n>>>>> On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:\n>>>>>> Receive updates from SLOF about the updated rtas-base.\n>>>>>> A separate patch for SLOF [1] (commit f9a60de3) adds\n>>>>>> functionality to invoke a private HCALL whenever OS\n>>>>>> issues instantiate-rtas with a new rtas-base.\n>>>>>>\n>>>>>> This is required as QEMU needs to know the updated rtas-base\n>>>>>> as it allocates error reporting structure in RTAS space upon\n>>>>>> a machine check exception.\n>>>>>>\n>>>>>> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html\n>>>>>>\n>>>>>> Signed-off-by: Aravinda Prasad \n>>>>>> Reviewed-by: David Gibson \n>>>>>\n>>>>> Ao I acked this earlier, but I've now realized there might be some\n>>>>> connection between this and discussions taking place elsewhere about\n>>>>> qemu not knowing what SLOF does with the device tree.\n>>>>>\n>>>>> At what point will SLOF call the UPDATE_RTAS hcall? I'm guessing at\n>>>>> the time of instantiate-rtas, is that right?\n>>>>\n>>>> The call happens from\n>>>> arch/powerpc/kernel/prom_init.c:prom_instantiate_rtas() and after that\n>>>> linux kernel makes two entries in the DT\n>>>>\n>>>> ....\n>>>> if (call_prom_ret(\"call-method\", 3, 2, &entry,\n>>>> ADDR(\"instantiate-rtas\"),\n>>>> rtas_inst, base) != 0\n>>>> || entry == 0) {\n>>>> prom_printf(\" failed\\n\");\n>>>> return;\n>>>> }\n>>>> prom_printf(\" done\\n\");\n>>>>\n>>>> reserve_mem(base, size);\n>>>>\n>>>> val = cpu_to_be32(base);\n>>>> prom_setprop(rtas_node, \"/rtas\", \"linux,rtas-base\",\n>>>> &val, sizeof(val));\n>>>> val = cpu_to_be32(entry);\n>>>> prom_setprop(rtas_node, \"/rtas\", \"linux,rtas-entry\",\n>>>> &val, sizeof(val));\n>>>> ....\n>>>>\n>>>> Quiesce is called after this. \n>>>>\n>>>>> Does SLOF put the RTAS blob address in its internal device tree, or\n>>>>> does it only pass it to the guest via the return parameters from\n>>>>> instantiate-rtas?\n>>>>\n>>>> Entry was made to the DT by linux kernel prom_init code, will this be\n>>>> visible to QEMU?\n>>>\n>>> With my recent SLOF FDT patch - yes:\n>>>\n>>> aik@fstn1-p1:~$ grep rtas dbg.dts\n>>> \trtas {\n>>> \t\tlinux,rtas-entry = <0x2fff0000>;\n>>> \t\tlinux,rtas-base = <0x2fff0000>;\n>>> [...]\n>>\n>> Ah.. except.. isn't that relying on the kernel putting the RTAS\n>> address into the device tree before it calls quiesce and kills SLOF?\n>>\n>> The SLOF image is bundled in with qemu, so it's ok for us to rely on\n>> its behaviour up to a point. It's not really ok for us to rely on the\n>> kernel's behaviour here, unless that behaviour is mandated by PAPR,\n>> which this isn't.\n> \n> Fair point.\n> \n>> So, I think we either need to have *SLOF* update the device tree with\n>> that address at instantiate-rtas time,\n> \n> I can do that, in a separate patch.\n\n\nOne comment though - if I create the properties in SLOF, I have to name\nthem different, like rtas-entry/rtas-base or slof,rtas-entry/slof,rtas-base\nto avoid colliding with the ones create by the guest kernel.\n\nSo what do I name them? And do we need 2 copies of the same thing, do we\never expect rtas-entry!=rtas-base? The guest can potentially get them\ndifferent (under powervm) but not with SLOF.\n\n\n> \n>> or we'll need to resurrect\n>> Aravinda's original UPDATE_RTAS hcall.","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\" (2048-bit key;\n\tunprotected) header.d=ozlabs-ru.20150623.gappssmtp.com\n\theader.i=@ozlabs-ru.20150623.gappssmtp.com\n\theader.b=\"gaXaYy5Y\"; dkim-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 3y6M160tVSz9sRm\n\tfor ;\n\tWed, 4 Oct 2017 14:32:58 +1100 (AEDT)","from localhost ([::1]:33014 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dzaQa-0002VB-54\n\tfor incoming@patchwork.ozlabs.org; Tue, 03 Oct 2017 23:32:56 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:46528)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dzaQ3-0002RI-NQ\n\tfor qemu-devel@nongnu.org; Tue, 03 Oct 2017 23:32:24 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dzaQ0-0006NT-KO\n\tfor qemu-devel@nongnu.org; Tue, 03 Oct 2017 23:32:23 -0400","from mail-pf0-x242.google.com ([2607:f8b0:400e:c00::242]:36143)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)\n\t(Exim 4.71) (envelope-from ) id 1dzaQ0-0006M3-7Q\n\tfor qemu-devel@nongnu.org; Tue, 03 Oct 2017 23:32:20 -0400","by mail-pf0-x242.google.com with SMTP id f84so11084592pfj.3\n\tfor ; Tue, 03 Oct 2017 20:32:19 -0700 (PDT)","from [10.61.2.175] ([122.99.82.10])\n\tby smtp.googlemail.com with ESMTPSA id\n\tq67sm27760821pfg.160.2017.10.03.20.32.13\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 03 Oct 2017 20:32:17 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ozlabs-ru.20150623.gappssmtp.com; s=20150623;\n\th=subject:from:to:cc:references:message-id:date:user-agent\n\t:mime-version:in-reply-to;\n\tbh=wcOq82RcjFBw6dT8vpaaDJI6S4g0Wpz9sSopHxF30+E=;\n\tb=gaXaYy5YA9OCH8e0Md8KhaV2FzZy2ocR/Auvw1CSL/YpDieHdNxO6sF0Fad4AMjaaZ\n\tZCHjFdfB0Tj6nLsd5FP3ijaiIN3m0QtkFKjiUAgmtKEk3h05v7WkZ96Gs4/LnxoimXB2\n\t/nqRCv7yHuelDZTEMiVLQm8RbVaIXwqh07MLco9YT4YTy1EOhXP13Prs7DGwPlvuXWXM\n\tbB0eK14lcrSabXcYcT6tqnmxyd7qIxMhqjSu4DSCZcKQU6HzJGtaTqLZMW3Vy8OZM/1c\n\t3jrg1jP/Cx+DX6RmD57thwvkds2QwdlhAqsx65JXuuw4uoEHKL8NmZnULWDUC2EdfBRt\n\t1+Ag==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:from:to:cc:references:message-id:date\n\t:user-agent:mime-version:in-reply-to;\n\tbh=wcOq82RcjFBw6dT8vpaaDJI6S4g0Wpz9sSopHxF30+E=;\n\tb=rUO6fCSTDAZC6OFPhgVYVN5YbbHngs7nYqG6E0Efn5veSU6rKWbH9+5Qgp0jcuRyLm\n\tXNDD4Esadb1Y5SHpeSQH+rvT87+EvKnvpQVFCKalqqcL2x4i+2mI/i1Ctdkwh6gko12v\n\tdAUo/TCTY1EC0eNXbE1mQY+L/yuNKLxf9G9MLyXxzJnAvh1JOKPdUJilw3UhkHarciFT\n\teg5tleHkHo4VmdwUAXP9BRGF47stsIBCrhaG6UoTLBb+aKO6Q3TGNtsnDh+pZuIvLOIb\n\thI8ZykvfDLXEQsh1L0pjdd+YD8qD6fHcf+2qEsP/UAWtbxcBHh5lYKGcRa4FkR1ZfTvU\n\twx4g==","X-Gm-Message-State":"AMCzsaUG4Iqx5OvotCn+QBHHNm1bzjcwJsz5l1gZM4L43X8uggEDUv5m\n\tvWuVfEwzKxTPwQToeEDePKfFxg==","X-Google-Smtp-Source":"AOwi7QBNYJm+FnzpE4xSmopbhrXzSLJfX3Q9xSWnykb4lfFFulD4LaRyvdIMGcc0iHJ3bxuWZPj9nw==","X-Received":"by 10.99.103.5 with SMTP id b5mr20322pgc.447.1507087938934;\n\tTue, 03 Oct 2017 20:32:18 -0700 (PDT)","From":"Alexey Kardashevskiy ","To":"David Gibson ","References":"<150659494872.25889.2069124544245723984.stgit@aravinda>\n\t<150659505839.25889.2018054058894535368.stgit@aravinda>\n\t<20170929061735.GD7712@umbus.fritz.box>\n\t<87y3oxen7t.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<95142cc0-518a-b7b7-4e56-cfc2adca36ba@ozlabs.ru>\n\t<20171003060757.GF3260@umbus.fritz.box>\n\t<4d649456-1242-febe-06bd-35bb01e3982b@ozlabs.ru>","Message-ID":"<8fa746ca-302f-b2bf-ee05-a4b0b4f2fcbb@ozlabs.ru>","Date":"Wed, 4 Oct 2017 14:32:11 +1100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<4d649456-1242-febe-06bd-35bb01e3982b@ozlabs.ru>","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"8TtbvdeT1GpFO0vkKPcetQspwviI20Hci\"","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2607:f8b0:400e:c00::242","X-Content-Filtered-By":"Mailman/MimeDel 2.1.21","Subject":"Re: [Qemu-devel] [Qemu-ppc] [PATCH v5 1/6] ppc: spapr: Register and\n\thandle HCALL to receive updated RTAS region","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":"benh@au1.ibm.com, Nikunj A Dadhania ,\n\tqemu-devel@nongnu.org, qemu-ppc@nongnu.org, sam.bobroff@au1.ibm.com, \n\tAravinda Prasad , paulus@samba.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1779455,"web_url":"http://patchwork.ozlabs.org/comment/1779455/","msgid":"<20171004055525.GT3260@umbus.fritz.box>","list_archive_url":null,"date":"2017-10-04T05:55:25","subject":"Re: [Qemu-devel] [Qemu-ppc] [PATCH v5 1/6] ppc: spapr: Register and\n\thandle HCALL to receive updated RTAS region","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Wed, Oct 04, 2017 at 02:32:11PM +1100, Alexey Kardashevskiy wrote:\n> On 03/10/17 20:12, Alexey Kardashevskiy wrote:\n> > On 03/10/17 17:07, David Gibson wrote:\n> >> On Mon, Oct 02, 2017 at 02:02:19PM +1100, Alexey Kardashevskiy wrote:\n> >>> On 29/09/17 21:52, Nikunj A Dadhania wrote:\n> >>>> David Gibson writes:\n> >>>>\n> >>>>> On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:\n> >>>>>> Receive updates from SLOF about the updated rtas-base.\n> >>>>>> A separate patch for SLOF [1] (commit f9a60de3) adds\n> >>>>>> functionality to invoke a private HCALL whenever OS\n> >>>>>> issues instantiate-rtas with a new rtas-base.\n> >>>>>>\n> >>>>>> This is required as QEMU needs to know the updated rtas-base\n> >>>>>> as it allocates error reporting structure in RTAS space upon\n> >>>>>> a machine check exception.\n> >>>>>>\n> >>>>>> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html\n> >>>>>>\n> >>>>>> Signed-off-by: Aravinda Prasad \n> >>>>>> Reviewed-by: David Gibson \n> >>>>>\n> >>>>> Ao I acked this earlier, but I've now realized there might be some\n> >>>>> connection between this and discussions taking place elsewhere about\n> >>>>> qemu not knowing what SLOF does with the device tree.\n> >>>>>\n> >>>>> At what point will SLOF call the UPDATE_RTAS hcall? I'm guessing at\n> >>>>> the time of instantiate-rtas, is that right?\n> >>>>\n> >>>> The call happens from\n> >>>> arch/powerpc/kernel/prom_init.c:prom_instantiate_rtas() and after that\n> >>>> linux kernel makes two entries in the DT\n> >>>>\n> >>>> ....\n> >>>> if (call_prom_ret(\"call-method\", 3, 2, &entry,\n> >>>> ADDR(\"instantiate-rtas\"),\n> >>>> rtas_inst, base) != 0\n> >>>> || entry == 0) {\n> >>>> prom_printf(\" failed\\n\");\n> >>>> return;\n> >>>> }\n> >>>> prom_printf(\" done\\n\");\n> >>>>\n> >>>> reserve_mem(base, size);\n> >>>>\n> >>>> val = cpu_to_be32(base);\n> >>>> prom_setprop(rtas_node, \"/rtas\", \"linux,rtas-base\",\n> >>>> &val, sizeof(val));\n> >>>> val = cpu_to_be32(entry);\n> >>>> prom_setprop(rtas_node, \"/rtas\", \"linux,rtas-entry\",\n> >>>> &val, sizeof(val));\n> >>>> ....\n> >>>>\n> >>>> Quiesce is called after this. \n> >>>>\n> >>>>> Does SLOF put the RTAS blob address in its internal device tree, or\n> >>>>> does it only pass it to the guest via the return parameters from\n> >>>>> instantiate-rtas?\n> >>>>\n> >>>> Entry was made to the DT by linux kernel prom_init code, will this be\n> >>>> visible to QEMU?\n> >>>\n> >>> With my recent SLOF FDT patch - yes:\n> >>>\n> >>> aik@fstn1-p1:~$ grep rtas dbg.dts\n> >>> \trtas {\n> >>> \t\tlinux,rtas-entry = <0x2fff0000>;\n> >>> \t\tlinux,rtas-base = <0x2fff0000>;\n> >>> [...]\n> >>\n> >> Ah.. except.. isn't that relying on the kernel putting the RTAS\n> >> address into the device tree before it calls quiesce and kills SLOF?\n> >>\n> >> The SLOF image is bundled in with qemu, so it's ok for us to rely on\n> >> its behaviour up to a point. It's not really ok for us to rely on the\n> >> kernel's behaviour here, unless that behaviour is mandated by PAPR,\n> >> which this isn't.\n> > \n> > Fair point.\n> > \n> >> So, I think we either need to have *SLOF* update the device tree with\n> >> that address at instantiate-rtas time,\n> > \n> > I can do that, in a separate patch.\n> \n> \n> One comment though - if I create the properties in SLOF, I have to name\n> them different, like rtas-entry/rtas-base or slof,rtas-entry/slof,rtas-base\n> to avoid colliding with the ones create by the guest kernel.\n\nThat's fine. I don't know if the kernel will error if the properties\nare already there or just overwrite them, but using new names might be\nsafer.\n\n> So what do I name them? And do we need 2 copies of the same thing,\n\nNeed, no, but if having 2 copies is the simpler approach that's fine.\n\n> do we\n> ever expect rtas-entry!=rtas-base? The guest can potentially get them\n> different (under powervm) but not with SLOF.\n\nMore to the point, qemu doesn't actually need to know the entry point\nfor the fwnmi stuff, only the base address.\n\n> \n> \n> > \n> >> or we'll need to resurrect\n> >> Aravinda's original UPDATE_RTAS hcall.\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=\"JgeDwL8Z\"; \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 3y6QKB1HtSz9t2M\n\tfor ;\n\tWed, 4 Oct 2017 17:02:06 +1100 (AEDT)","from localhost ([::1]:33276 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dzcku-0002RG-A0\n\tfor incoming@patchwork.ozlabs.org; Wed, 04 Oct 2017 02:02:04 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:36724)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dzckQ-0002Qw-Va\n\tfor qemu-devel@nongnu.org; Wed, 04 Oct 2017 02:01:36 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dzckN-0003qo-SE\n\tfor qemu-devel@nongnu.org; Wed, 04 Oct 2017 02:01:35 -0400","from ozlabs.org ([103.22.144.67]:46467)\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 1dzckN-0003qA-4n; Wed, 04 Oct 2017 02:01:31 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3y6QJQ5dqSz9t2M; Wed, 4 Oct 2017 17:01:26 +1100 (AEDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1507096886;\n\tbh=d/bdGAbdU4sArGDLXeRUpPK4Uh9jvGUjlQqf8moZswo=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=JgeDwL8ZI//n6UVIdMOWbbjEq/hSnA1J9+SAUup2YUGlPosxsgDPAuMJBejIXB8HT\n\tMeIiFlR39P6ppc2wvk7AYMz52Yhq0RY/8EhFotnxo7PTwFfs9hbdEnkeE9IYphShcy\n\tQTw+JIQiOcP85FtKZLBchoRSO8UvKXkB2JlXagXY=","Date":"Wed, 4 Oct 2017 16:55:25 +1100","From":"David Gibson ","To":"Alexey Kardashevskiy ","Message-ID":"<20171004055525.GT3260@umbus.fritz.box>","References":"<150659494872.25889.2069124544245723984.stgit@aravinda>\n\t<150659505839.25889.2018054058894535368.stgit@aravinda>\n\t<20170929061735.GD7712@umbus.fritz.box>\n\t<87y3oxen7t.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<95142cc0-518a-b7b7-4e56-cfc2adca36ba@ozlabs.ru>\n\t<20171003060757.GF3260@umbus.fritz.box>\n\t<4d649456-1242-febe-06bd-35bb01e3982b@ozlabs.ru>\n\t<8fa746ca-302f-b2bf-ee05-a4b0b4f2fcbb@ozlabs.ru>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"tRcR9GoWqjXrt11v\"","Content-Disposition":"inline","In-Reply-To":"<8fa746ca-302f-b2bf-ee05-a4b0b4f2fcbb@ozlabs.ru>","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] [Qemu-ppc] [PATCH v5 1/6] ppc: spapr: Register and\n\thandle HCALL to receive updated RTAS region","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":"benh@au1.ibm.com, Nikunj A Dadhania ,\n\tqemu-devel@nongnu.org, qemu-ppc@nongnu.org, sam.bobroff@au1.ibm.com, \n\tAravinda Prasad , paulus@samba.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}}]