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.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 B5E86C433DF for ; Wed, 24 Jun 2020 17:05:41 +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 8346620578 for ; Wed, 24 Jun 2020 17:05:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="eziwITDI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8346620578 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.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 1jo8ps-0002BO-Un; Wed, 24 Jun 2020 17:05:20 +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 1jo8pr-0002BJ-H3 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 17:05:19 +0000 X-Inumbo-ID: e1570683-b63c-11ea-8110-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e1570683-b63c-11ea-8110-12813bfff9fa; Wed, 24 Jun 2020 17:05:18 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A570F20578; Wed, 24 Jun 2020 17:05:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593018318; bh=/UnoLMxQONCLkO5gVNRqe1RRYpEGc4XdR1M7cDuR7wU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=eziwITDIF+H1hXY9h2BK/lfMeYS1S49w7sbf7HlS/Du8UZVzKP1an8MAbwK2CTiNz BbnVzGxbJ4AZ27KNCUpsGE7xkBTAOVaJC8SBsNRLI/JZjxNyfhZeyegqqAeDqawpOP 94fWFUQAE27WOIBUiCH9Y/WSyBtbWZsC8Yyp4RFk= Date: Wed, 24 Jun 2020 10:05:17 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Oleksandr Andrushchenko Subject: Re: UEFI support in ARM DomUs In-Reply-To: Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> <271a4db0-5ce5-ba25-65e7-107c040f5069@epam.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 , Stefano Stabellini , Julien Grall , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 24 Jun 2020, Oleksandr Andrushchenko wrote: > On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote: > > > > On 6/23/20 4:20 AM, Stefano Stabellini wrote: > >> On Mon, 22 Jun 2020, Julien Grall wrote: > >>>>>> For the first part (__XEN_INTERFACE_VERSION__) I think we can provide it > >>>>>> via > >>>>>> > >>>>>> CFLAGS or something. This can also be done for the location of Xen > >>>>>> headers. > >>>>> __XEN_INTERFACE_VERSION__ should work through the CFLAGS. An alternative > >>>>> would be to allow the user to specify through the Kconfig. > >>>> You mean specifying via Kconfig something like "0x00040d00"? > >>> Possibly yes. > >>> > >>>> And what about the headers? How will we provide their location if we decide > >>>> not to include those > >>>> > >>>> in the tree? > >>> I would do through Kconfig as well. > >> If we specify the external location of the Xen headers via Kconfig, it > >> seems to me that we should be able to detect the interface version > >> automatically from any Makefile as part of the build. No need to ask the > >> user. > >> > >> However, if Oleksandr is thinking of using the Xen headers for the > >> hypercalls definitions, then I think we might not need external headers > >> at all because that is a stable interface, as Julien wrote. We could > >> just define our own few headers for just what you need like Linux does. > > > > This is a good idea: I'll try to get the minimal set of headers from Linux > > > > instead of Xen as those seem to be well prepared for such a use-case. This > > > > way we'll have headers in U-boot tree and guarantee that we have a minimal > > > > subset which is easier to maintain. I'll keep you updated on the progress > > We've managed to strip the headers and remove __XEN__ and the rest definitions > > we were talking about. So, these are now the minimal required set of headers > > that allows U-boot to build serial and block drivers. Please take a look at [1] > > Pull request for comments is at [2] I think this is the right approach. There is no build-dependency on Xen anymore, is that correct?