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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 5622FC4707A for ; Sun, 23 May 2021 11:25:44 +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 AD8AE61057 for ; Sun, 23 May 2021 11:25:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD8AE61057 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=eik.bme.hu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:38560 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkmEo-0005i5-OB for qemu-devel@archiver.kernel.org; Sun, 23 May 2021 07:25:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52764) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkmDf-00050x-CY; Sun, 23 May 2021 07:24:31 -0400 Received: from zero.eik.bme.hu ([152.66.115.2]:56073) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkmDd-00025V-5d; Sun, 23 May 2021 07:24:31 -0400 Received: from zero.eik.bme.hu (blah.eik.bme.hu [152.66.115.182]) by localhost (Postfix) with SMTP id E072E74570D; Sun, 23 May 2021 13:24:26 +0200 (CEST) Received: by zero.eik.bme.hu (Postfix, from userid 432) id 53617745708; Sun, 23 May 2021 13:24:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id 4E95B7456B4; Sun, 23 May 2021 13:24:26 +0200 (CEST) Date: Sun, 23 May 2021 13:24:26 +0200 (CEST) From: BALATON Zoltan To: Alexey Kardashevskiy Subject: Re: [PATCH qemu v20] spapr: Implement Open Firmware client interface In-Reply-To: <8e2d201d-a6a3-72bc-5d0f-5226930f1cbc@ozlabs.ru> Message-ID: <8c712d-a369-4db-177e-2a5e63836af4@eik.bme.hu> References: <20210520090557.435689-1-aik@ozlabs.ru> <5825cde5-a408-a438-116d-5a9d9113a52a@ozlabs.ru> <8527c8d2-c1e7-b3f8-0bda-529ba3864701@ozlabs.ru> <77716be-4cf7-d222-d465-13685bf0783a@eik.bme.hu> <8e2d201d-a6a3-72bc-5d0f-5226930f1cbc@ozlabs.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3866299591-1273654669-1621769066=:72420" Received-SPF: pass client-ip=152.66.115.2; envelope-from=balaton@eik.bme.hu; helo=zero.eik.bme.hu X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3866299591-1273654669-1621769066=:72420 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 23 May 2021, Alexey Kardashevskiy wrote: > On 23/05/2021 01:02, BALATON Zoltan wrote: >> On Sat, 22 May 2021, BALATON Zoltan wrote: >>> On Sat, 22 May 2021, Alexey Kardashevskiy wrote: >>>> VOF itself does not prints anything in this patch. >>> >>> However it seems to be needed for linux as the first thing it does seems >>> to be getting /chosen/stdout and calls exit if it returns nothing. So I'll >>> need this at least for linux. (I think MorphOS may also query it to print >>> a banner or some messages but not sure it needs it, at least it does not >>> abort right away if not found.) >>> >>>>> but to see Linux output do I need a stdout in VOF or it will just open >>>>> the serial with its own driver and use that? >>>>> So I'm not sure what's the stdout parts in the current vof patch does >>>>> and if I need that for anything. I'll try to experiment with it some >>>>> more but fixing the ld and Kconfig seems to be enough to get it work for >>>>> me. >>>> >>>> So for the client to print something, /chosen/stdout needs to have a >>>> valid ihandle. >>>> The only way to get a valid ihandle is having a valid phandle which >>>> vof_client_open() can open. >>>> A valid phandle is a phandle of any node in the device tree. On spapr we >>>> pick some spapr-vty, open it and store in /chosen/stdout. >>>> >>>> From this point output from the client can be seen via a tracepoint. >> >> I've got it now. Looking at the original firmware device tree dump: >> >> https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2/attach/PegasosII_OFW-Dump.txt >> >> I see that /chosen/stdout points to "screen" which is an alias to >> /bootconsole. Just adding an empty /bootconsole node in the device tree and >> vof_client_open_store() that as /chosen/stdout works and I get output via >> vof_write traces so this is enough for now to test Linux. Properly >> connecting a serial backend can thus be postponed. >> >> So with this the Linux kernel does not abort on the first device tree >> access but starts to decompress itself then the embedded initrd and crashes >> at calling setprop: >> >> [...] >> vof_client_handle: setprop >> >> Thread 4 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault. >> (gdb) bt >> #0  0x0000000000000000 in  () >> #1  0x0000555555a5c2bf in vof_setprop >>     (vof=0x7ffff48e9420, vallen=4, valaddr=, >> pname=, nodeph=8, fdt=0x7fff8aaff010, ms=0x5555564f8800) >>     at ../hw/ppc/vof.c:308 >> #2  0x0000555555a5c2bf in vof_client_handle >>     (nrets=1, rets=0x7ffff48e93f0, nargs=4, args=0x7ffff48e93c0, >> service=0x7ffff48e9460 "setprop", >>      vof=0x7ffff48e9420, fdt=0x7fff8aaff010, ms=0x5555564f8800) at >> ../hw/ppc/vof.c:842 >> #3  0x0000555555a5c2bf in vof_client_call >>     (ms=0x5555564f8800, vof=vof@entry=0x55555662a3d0, >> fdt=fdt@entry=0x7fff8aaff010, args_real=args_real@entry=23580472) >>     at ../hw/ppc/vof.c:935 >> >> loooks like it's trying to set /chosen/linux,initrd-start: > > It is not horribly clear why it crashed though. It crashed becuase I had TYPE_VOF_MACHINE_IF but did not set a setprop callback and it tried to call that here. Adding a {return true;} empty callback avoids this. >> (gdb) up >> #1  0x0000555555a5c2bf in vof_setprop (vof=0x7ffff48e9420, vallen=4, >> valaddr=, pname=, nodeph=8, >>     fdt=0x7fff8aaff010, ms=0x5555564f8800) at ../hw/ppc/vof.c:308 >> 308            if (!vmc->setprop(ms, nodepath, propname, val, vallen)) { >> (gdb) p nodepath >> $1 = "/chosen\000\060/rPC,750CXE/", '\000' >> (gdb) p propname >> $2 = >> "linux,initrd-start\000linux,initrd-end\000linux,cmdline-timeout\000bootarg" >> (gdb) p val >> $3 = >> >> I think I need the callback for setprop in TYPE_VOF_MACHINE_IF. I can copy >> spapr_vof_setprop() but some explanation on why that's needed might help. >> Ciould I just do fdt_setprop in my callback as vof_setprop() would do >> without a machine callback or is there some special handling needed for >> these properties? > > The short answer is yes, you do not need TYPE_VOF_MACHINE_IF. > > The long answer is that we build the FDT on spapr twice: > 1. at the reset time and > 2. after "ibm,client-arhitecture-support" (early in the boot the spapr > paravirtual client says what it supports - ISA level, MMU features, etc) > > Between 1 and 2 the kernel moves initrd and we do not update the QEMU's > version of its location, the tree at 2) will have the old values. > > So for that reason I have TYPE_VOF_MACHINE_IF. You most definitely do not > need it. I need TYPE_VOF_MACHINE_IF because that has the quiesce callback that I need to shut VOF down when the guest is finished with it otherwise it would crash later (more on this in next message). But since I shut down VOF here I don't need to remember changes to the FDT so I can just use an empty setprop callback. (I wouldn't even need that if VOF would check that a callback is non-NULL before calling it.) Regards, BALATON Zoltan --3866299591-1273654669-1621769066=:72420--