From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLACK,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B6ABC76188 for ; Fri, 19 Jul 2019 08:08:52 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 43A842084D for ; Fri, 19 Jul 2019 08:08:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 43A842084D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:42932 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hoNwh-0000wz-AZ for qemu-devel@archiver.kernel.org; Fri, 19 Jul 2019 04:08:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45047) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hoNwR-0000DX-9z for qemu-devel@nongnu.org; Fri, 19 Jul 2019 04:08:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hoNwP-0005db-Sf for qemu-devel@nongnu.org; Fri, 19 Jul 2019 04:08:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40622) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hoNwP-0005cu-L8; Fri, 19 Jul 2019 04:08:33 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E759B30C7468; Fri, 19 Jul 2019 08:08:31 +0000 (UTC) Received: from thuth.remote.csb (dhcp-192-187.str.redhat.com [10.33.192.187]) by smtp.corp.redhat.com (Postfix) with ESMTP id D3FEC6012C; Fri, 19 Jul 2019 08:08:30 +0000 (UTC) To: Alexey Kardashevskiy , Greg Kurz References: <20190716053522.78813-1-aik@ozlabs.ru> <8b727864-1634-0a5d-c557-fcaa52c49434@redhat.com> <9587706e-d53c-5490-cb4a-4c89eadfc497@ozlabs.ru> <20190718124042.4dd7b132@bahia.lab.toulouse-stg.fr.ibm.com> <8ed62115-29a2-c742-f309-0eb92a159803@redhat.com> <32ff3964-977e-8023-9a3b-529710ae054b@ozlabs.ru> From: Thomas Huth Openpgp: preference=signencrypt Autocrypt: addr=thuth@redhat.com; keydata= xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzRxUaG9tYXMgSHV0 aCA8dGguaHV0aEBnbXguZGU+wsF7BBMBAgAlAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIX gAUCUfuWKwIZAQAKCRAu2dd0/nAttbe/EACb9hafyOb2FmhUqeAiBORSsUifFacQ7laVjcgR I4um8CSHvxijYftpkM2EdAtmXIKgbNDpQoXcWLXB9lu9mLgTO4DVT00TRR65ikn3FCWcyT74 ENTOzRKyKLsDCjhXKPblTPIQbYAUCOWElcyAPm0ERd62fA/rKNxgIiNo/l4UODOMoOJm2/Ox ZoTckW68Eqv7k9L7m7j+Hn3hoDTjAmcCBJt+j7pOhzWvCbqoNOIH8C8qvPaNlrba+R/K6jkO 6jZkTbYQpGIofEQJ/TNn38IsNGpI1ALTHWFtoMxp3j2Imz0REO6dRE2fHRN8sVlHgkoeGhmY NbDsDE1jFQOEObFnu0euk//7BXU7tGOHckVAZ8T1smiRPHfQU7UEH2a/grndxJ+PNeM5w7n2 l+FN3cf2KgPotCK2s9MjSdZA7C5e3rFYO8lqiqTJKvc62vqp3e7B0Kjyy5/QtzSOejBij2QL xkKSFNtxIz4MtuxN8e3IDQNxsKry3nF7R4MDvouXlMo6wP9KuyNWb+vFJt9GtbgfDMIFVamp ZfhEWzWRJH4VgksENA4K/BzjEHCcbTUb1TFsiB1VRnBPJ0SqlvifnfKk6HcpkDk6Pg8Q5FOJ gbNHrdgXsm+m/9GF2zUUr+rOlhVbK23TUqKqPfwnD7uxjpakVcJnsVCFqJpZi1F/ga9IN87B TQRR+3lMARAAtp831HniPHb9AuKq3wj83ujZK8lH5RLrfVsB4X1wi47bwo56BqhXpR/zxPTR eOFT0gnbw9UkphVc7uk/alnXMDEmgvnuxv89PwIQX6k3qLABeV7ykJQG/WT5HQ6+2DdGtVw3 2vjYAPiWQeETsgWRRQMDR0/hwp8s8tL/UodwYCScH6Vxx9pdy353L1fK4Bb9G73a+9FPjp9l x+WwKTsltVqSBuSjyZQ3c3EE8qbTidXZxB38JwARH8yN3TX+t65cbBqLl/zRUUUTapHQpUEd yoAsHIml32e4q+3xdLtTdlLi7FgPBItSazcqZPjEcYW73UAuLcmQmfJlQ5PkDiuqcitn+KzH /1pqsTU7QFZjbmSMJyXY0TDErOFuMOjf20b6arcpEqse1V3IKrb+nqqA2azboRm3pEANLAJw iVTwK3qwGRgK5ut6N/Znv20VEHkFUsRAZoOusrIRfR5HFDxlXguAdEz8M/hxXFYYXqOoaCYy 6pJxTjy0Y/tIfmS/g9Bnp8qg9wsrsnk0+XRnDVPak++G3Uq9tJPwpJbyO0vcqEI3vAXkAB7X VXLzvFwi66RrsPUoDkuzj+aCNumtOePDOCpXQGPpKl+l1aYRMN/+lNSk3+1sVuc2C07WnYyE gV/cbEVklPmKrNwu6DeUyD0qI/bVzKMWZAiB1r56hsGeyYcAEQEAAcLBXwQYAQIACQUCUft5 TAIbDAAKCRAu2dd0/nAttYTwEACLAS/THRqXRKb17PQmKwZHerUvZm2klo+lwQ3wNQBHUJAT p2R9ULexyXrJPqjUpy7+voz+FcKiuQBTKyieiIxO46oMxsbXGZ70o3gxjxdYdgimUD6U8PPd JH8tfAL4BR5FZNjspcnscN2jgbF4OrpDeOLyBaj6HPmElNPtECHWCaf1xbIFsZxSDGMA6cUh 0uX3Q8VI7JN1AR2cfiIRY7NrIlWYucJxyKjO3ivWm69nCtsHiJ0wcF8KlVo7F2eLaufo0K8A ynL8SHMF3VEyxsXOP2f1UR9T2Ur30MXcTBpjUxml1TX3RWY5uH89Js/jlIugBwuAmacJ7JYh lTg6sF/GNc4nPb4kk2yktNWTade+TzsllYlJPaorD2Qe8qX0iFUhFC6y9+O6mP4ZvWoYapp9 ezYNuebMgEr93ob1+4sFg3812wNP01WqsGtWCJHnPv/JoonFdMzD/bIkXGEJMk6ks2kxQQZq g6Ik/s/vxOfao/xCn8nHt7GwvVy41795hzK6tbSl+BuyCRp0vfPRP34OnK7+jR2nvQpJu/pU rCELuGwT9hsYkUPjVd4lfylN3mzEc6iAv/wwjsc0DRTSQCpXT3v2ymTAsRKrVaEZLibTXaf+ WslxWek3xNYRiqwwWAJuL652eAlxUgQ5ZS+fXBRTiQpJ+F26I/2lccScRd9G5w== Organization: Red Hat Message-ID: <6483cf4e-dd49-819b-cfe5-6e3ce50bb99e@redhat.com> Date: Fri, 19 Jul 2019 10:08:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <32ff3964-977e-8023-9a3b-529710ae054b@ozlabs.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Fri, 19 Jul 2019 08:08:32 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr: Stop providing RTAS blob X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, David Gibson Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 19/07/2019 03.23, Alexey Kardashevskiy wrote: >=20 >=20 > On 18/07/2019 20:49, Thomas Huth wrote: >> On 18/07/2019 12.40, Greg Kurz wrote: >>> On Thu, 18 Jul 2019 17:55:12 +1000 >>> Alexey Kardashevskiy wrote: >>> >>>> >>>> >>>> On 18/07/2019 17:20, Thomas Huth wrote: >>>>> On 16/07/2019 07.35, Alexey Kardashevskiy wrote: >>>>>> SLOF implements one itself so let's remove it from QEMU. It is one >>>>>> less >>>>>> image and simpler setup as the RTAS blob never stays in its >>>>>> initial place >>>>>> anyway as the guest OS always decides where to put it. >>>>>> >>>>>> This totally depends on https://patchwork.ozlabs.org/patch/1132440= / , >>>>>> hence RFC. >>>>> >>>>> Patch looks basically fine for me, but I wonder whether we should w= ait >>>>> for one or two releases until we really remove it from QEMU, so >>>>> that it >>>>> is still possible to test the latest QEMU with older SLOF releases >>>>> for a >>>>> while (which is sometimes useful when hunting bugs). Or should this >>>>> maybe even go through the official deprecation process (i.e. with a= n >>>>> entry in qemu-deprecated.texi)? >>>> >>>> I worry more about slof being distributed as a separate package in >>>> RHEL, >>>> easy enough to get qemu/slof out of sync. >>>> >>> >>> Then it seems to call for keeping the code around in QEMU in case RHE= L's >>> slof doesn't implement the RTAS blob. Following the official deprecat= ion >>> process looks like a good option IMHO. >> >> We can of course make the qemu rpm depend on the new SLOF rpm, so that >> you can not install an older SLOF with a newer QEMU. >=20 > Cool, let's do that. >=20 >> But anyway, to avoid confusion and ease debugging, >=20 > There is a little confusion ("why did the guest stop after Device tree > struct=C2=A0 0x000000000aff0000 -> 0x000000000b000000") and what will m= ake > the debugging harder if we drop rtas from qemu now? I think I should > have known the answer by now but I do not :) I meant bugs where you are not sure whether it's a problem of QEMU or SLOF. In that case, it's useful to use older SLOF versions with newer QEMU versions, to see where it breaks. But since SLOF is not that much updated recently, I think it's not so important to keep this "feature". >> I'd also rather vote >> for the official deprecation process here, and remove the RTAS blob fr= om >> QEMU after the official deprecation period. >=20 > We won't be able to enjoy one less binary for another year and we > already have bugs fixes for which would benefit from not having rtas bl= ob. Ok, if you have other things in the pipe that depend on this clean-up, then please ignore my suggestion and remove it right away. It's not a "feature" that was directly visible to the guest OS or the users, so I don't think we urgently need the deprecation process here. Thomas