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=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,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 0A733C433DF for ; Thu, 18 Jun 2020 14:50:51 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 C5F8720739 for ; Thu, 18 Jun 2020 14:50:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=xen.org header.i=@xen.org header.b="tKfNQ4/0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C5F8720739 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvsD-0003Mm-6z; Thu, 18 Jun 2020 14:50:37 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvsB-0003Mb-Uc for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 14:50:35 +0000 X-Inumbo-ID: 0e752a5a-b173-11ea-baa8-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0e752a5a-b173-11ea-baa8-12813bfff9fa; Thu, 18 Jun 2020 14:50:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Yu0MZi/6HCce73HsqklCSPKPrUWmB2tMw9OQRD7ZdtY=; b=tKfNQ4/0vjC7yAW4yVe1NNKdUM 4gvBJKp9rjto+ZTz9MLL4HqVD7snSwdi0UK2UOrMszz2YI5y1mtpIOmu+0FY3R9mHwrV4CibI+hTJ 7lw/Ymk6pSO6TjlIkpZt7roJKlzhPQMGH3ECXWELR1F/GB+Qxb36rQSAOvHlKpJihtSc=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvs4-0002No-S2; Thu, 18 Jun 2020 14:50:28 +0000 Received: from 54-240-197-234.amazon.com ([54.240.197.234] helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jlvs4-0004O7-Kq; Thu, 18 Jun 2020 14:50:28 +0000 Subject: Re: UEFI support in ARM DomUs To: Oleksandr Andrushchenko , Stefano Stabellini References: From: Julien Grall Message-ID: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> Date: Thu, 18 Jun 2020 15:50:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18/06/2020 06:22, Oleksandr Andrushchenko wrote: > > On 6/4/20 6:31 PM, Stefano Stabellini wrote: >> On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote: >>> On 6/4/20 4:57 AM, Peng Fan wrote: >>>> Grall ; >>>>> Nataliya Korovkina >>>>> Subject: UEFI support in ARM DomUs >>>> We have made U-Boot run inside XEN DomU, but just only PV console part, >>>> not implement other frontend drivers currently. Would this help for your >>>> case if enable EFI in U-Boot? >>> Well, we have a working PV block implementation on top of that on iMX8 >>> >>> platform, mostly ported from mini-os. Currently we are finalizing the work >>> >>> and cleaning up (it's going to take a week or so hopefully). Then, we we'll post >>> >>> it on our public github. We are also thinking about upstreaming the work, but it may >>> >>> take quite some time if the whole idea fits u-boot's view on such an extension at all. >> Yes please to both of you! :-) >> >> In the meantime, while we wait for those changes to go upstream in >> uboot, could you please post a branch on github and a link on this email >> thread? > > It took a bit more time than we expected, but here we go [1]: > > this is in form of a pull-request as we would love to hear from the > > community and it is easier to discuss the code (please leave comments there) > > 1. There is code originating from MiniOS and work done by Peng, so we > > would like to ask the respective copyright owners to raise their hands and Not everyone are closely watching xen-devel. So if you want to find out who are the copyright owners, then your best solution is to go through the git log and CC the authors. > > let us *fix inappropriate licensing* if any. > > 2. Please note, the series has a HACK to move the RAM base as it is expected by > > our test platform (iMX8), so others will need to remove or modify that. > > 3. There is a limitation already noted by Peng that we do not have serial output > > until MMU is setup, so we have introduced xen_early_printk helper which always > > works, so you can use that for early stage debugging. > > 4. Minimal memory size supported is ~129M because of dtb placement by Xen tools Hmmm... Why? What's wrong with booting a guest with just 64MB? > > 5. We use -D__XEN__ to access some of the hidden defines we need such as > > GUEST_RAM0_BASE and the friends as there is no other way but manually defining the > > same which is not cute. I have replied to this in the pull request. But I want to bring the conversation here to have a wider discussion. For a first, __XEN__ should really only be defined by the hypervisor and not used by the guest. This is used to gate non-stable ABI (such as the tools) and anything behind it hasn't been vetted to work in other build configuration that the one used by Xen. In general, we expect the guest to discover everything for the device-tree because the memory layout is not stable (we want to be able to reshuffle as we add more features). I know that EDK2/Tianocore can be built once and work on every Xen configuration. It would be ideal that U-boot follow the same. If it is really not possible, then we should explore a path that is preventing to define __XEN__. How much does U-boot expect to know about the memory layout? Does it require to know all the memory banks? Or would it be sufficient for it to know the start address of the first bank and the minimum of RAM? Cheers, -- Julien Grall