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 A3369C433E6 for ; Tue, 23 Feb 2021 09:13:12 +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 CDA5B64E4D for ; Tue, 23 Feb 2021 09:13:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CDA5B64E4D 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]:58504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lETkk-00014k-HH for qemu-devel@archiver.kernel.org; Tue, 23 Feb 2021 04:13:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45850) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lETjl-0000YS-P2; Tue, 23 Feb 2021 04:12:09 -0500 Received: from zero.eik.bme.hu ([2001:738:2001:2001::2001]:49003) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lETji-00034i-Cj; Tue, 23 Feb 2021 04:12:08 -0500 Received: from zero.eik.bme.hu (blah.eik.bme.hu [152.66.115.182]) by localhost (Postfix) with SMTP id 6A5D57462D3; Tue, 23 Feb 2021 10:12:01 +0100 (CET) Received: by zero.eik.bme.hu (Postfix, from userid 432) id 310267456B7; Tue, 23 Feb 2021 10:12:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id 2F5547456B4; Tue, 23 Feb 2021 10:12:01 +0100 (CET) Date: Tue, 23 Feb 2021 10:12:01 +0100 (CET) From: BALATON Zoltan To: David Gibson Subject: Re: [PATCH qemu v13] spapr: Implement Open Firmware client interface In-Reply-To: Message-ID: References: <20210209110252.110107-1-aik@ozlabs.ru> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Received-SPF: pass client-ip=2001:738:2001:2001::2001; envelope-from=balaton@eik.bme.hu; helo=zero.eik.bme.hu X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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: Alexey Kardashevskiy , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Greg Kurz Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, 23 Feb 2021, David Gibson wrote: > On Tue, Feb 23, 2021 at 04:01:00PM +1100, Alexey Kardashevskiy wrote: >> On 23/02/2021 14:07, David Gibson wrote: >>> On Tue, Feb 09, 2021 at 10:02:52PM +1100, Alexey Kardashevskiy wrote: >>>> #endif /* HW_SPAPR_H */ >>> >>> VOF is pretty much inherently papr specific, so I'm not really seeing >>> a clear rationale for the distinction between vof_*() things and >>> spapr_vof_*() things. >> >> spapr_vof_ uses SpaprMachineState, vof_ does not and can be used ... I do >> not know... for macs? freescale? >> >> I thought it might be useful for whatever Balaton Zoltran wanted to use it >> for. > > Hmm, I hadn't thought of that sort of application. I guess that's a > point. > > I feel like the call for vof is less for those platforms, because they > admit a full in-guest firmware implementation, whereas the paravirt > nature of papr means that some components have to go into the > hypervisor. The immediate plan is to try to use vof for pegasos2 as replacement firmware to be able to at least boot guests without needing a non-distributable firmware blob (as mentioned and further explained on https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2). This seems to be a better option than reimplementing its firmware which would then be yet another OpenFirmware implementation in QEMU. I was waiting for vof to get in before trying to actually implement that to avoid to need too much rebasing but in theory it could work. It's true we don't have a hypervisor on those platforms but could have one at least while the firmware is running to avoid having to do everything in guest firmware. Most guests just query the device tree via client interface and vof should be enough for that. I'm not sure about RTAS but that's a small problem if this allows to boot guests without having to write a whole guest open firmware implementation. >>> Vof is pretty unavoidably tied to spapr, so I don't think you really >>> need an interface to abstract this. >> >> Balaton Zoltran asked for that, more or less :) This was my original comment: https://lists.nongnu.org/archive/html/qemu-ppc/2020-12/msg00063.html One reason is to keep vof reusable but also to make it clear what are the changes to spapr that was previously hard to distinguish from what's part of vof itself. Regards, BALATON Zoltan