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 2DDE2C433E0 for ; Tue, 23 Jun 2020 01:20:57 +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 ED07120675 for ; Tue, 23 Jun 2020 01:20:56 +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="P/7pAL/y" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED07120675 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 1jnXcD-0002e0-CC; Tue, 23 Jun 2020 01:20:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnXcC-0002dq-HX for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 01:20:44 +0000 X-Inumbo-ID: c232a7c8-b4ef-11ea-8496-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c232a7c8-b4ef-11ea-8496-bc764e2007e4; Tue, 23 Jun 2020 01:20:44 +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 0596F20675; Tue, 23 Jun 2020 01:20:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592875243; bh=wcXgJbJlUk8bITf2CCrZAFYv+RTmBjCLBeNZ0Mjjr1A=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=P/7pAL/yZr8dYQ000cFXro1hRptCvQ//z1CZ0wvZ7Fya81RQWR68KmqAk/gfRbdFV JEtg10HadkzageiEQRdmG+bOym7WIlXqTvxqGPQ4z4tSFPyoXxi+neE7F+gLGJxHQp QJyxuhhoJi5PvfW+glbV+hf9wQ6AsVyeUkczs8a4= Date: Mon, 22 Jun 2020 18:20:42 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: UEFI support in ARM DomUs In-Reply-To: <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> 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> 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 , Oleksandr Andrushchenko , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" 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. If you can do that, I think it would be better because we decouple the UBoot build from the Xen build completely. We don't even need the Xen tree checked out to build UBoot. It would be a huge advantage because it makes it far easier to build-test changes for others in the community that don't know about Xen and also it becomes far easier to integrate into any build system.