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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 29633C004D4 for ; Wed, 18 Jan 2023 11:00:26 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.480486.744926 (Exim 4.92) (envelope-from ) id 1pI6Ak-0005oo-H9; Wed, 18 Jan 2023 11:00:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 480486.744926; Wed, 18 Jan 2023 11:00:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pI6Ak-0005o0-Co; Wed, 18 Jan 2023 11:00:02 +0000 Received: by outflank-mailman (input) for mailman id 480486; Wed, 18 Jan 2023 11:00:01 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pI6Aj-0005i9-SU for xen-devel@lists.xenproject.org; Wed, 18 Jan 2023 11:00:01 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pI6Aj-0006Jl-7G; Wed, 18 Jan 2023 11:00:01 +0000 Received: from 54-240-197-231.amazon.com ([54.240.197.231] helo=[192.168.8.239]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pI6Aj-0008In-1S; Wed, 18 Jan 2023 11:00:01 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" 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:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=+jrDTHJzP6DIlIJuk91UB+u8pUB+1hkyR01Pw/bysxA=; b=2klbXRBHPymdBmD54Ghgd3WBCr Lh0OXZZ0qRS05OBF6C7N8Qhb8G5HwuzUklnZJKikR5HR6DhPw6cQvWfmdtjWcLWzdnY5L/Wb9AMHz QZHsEqW1wSev2/aKJXMOuceiJmFvptBdLAM3vEa1DqLqzdL86O+AJMWf/+dzzGiMPbEM=; Message-ID: Date: Wed, 18 Jan 2023 10:59:59 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v2 04/40] xen/arm: add an option to define Xen start address for Armv8-R Content-Language: en-US To: Wei Chen , Penny Zheng , "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , Jiamei Xie References: <20230113052914.3845596-1-Penny.Zheng@arm.com> <20230113052914.3845596-5-Penny.Zheng@arm.com> <7ffe5d34-614d-f2aa-cf87-c518917c970a@xen.org> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 18/01/2023 10:22, Wei Chen wrote: >>> Although it is unlikely that vendors using the Armv8-R IP will do so, it >>> is indeed an option. In the ID register, there are also related bits in >>> ID_AA64MMFR0_EL1 (MSA_frac) to indicate this. >>> >>>>> --- >>>>> xen/arch/arm/Kconfig | 8 ++++++++ >>>>> xen/arch/arm/platforms/Kconfig | 16 +++++++++++++--- >>>>> 2 files changed, 21 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig >>>>> index ace7178c9a..c6b6b612d1 100644 >>>>> --- a/xen/arch/arm/Kconfig >>>>> +++ b/xen/arch/arm/Kconfig >>>>> @@ -145,6 +145,14 @@ config TEE >>>>> This option enables generic TEE mediators support. It allows >>>> guests >>>>> to access real TEE via one of TEE mediators implemented in >> XEN. >>>>> >>>>> +config XEN_START_ADDRESS >>>>> + hex "Xen start address: keep default to use platform defined >>>> address" >>>>> + default 0 >>>>> + depends on ARM_V8R >>>> >>>> It is still pretty unclear to me what would be the difference between >>>> HAS_MPU and ARM_V8R. >>>> >>> >>> If we don't want to support non-MPU supported Armv8-R, I think they are >> the >>> same. IMO, non-MPU supported Armv8-R is meaningless to Xen. >> OOI, why do you think this is meaningless? > > If there is Armv8-R board without EL2 MPU, how can we protect Xen? So what you call EL2 MPU is an MPU that is following the Arm specification. In theory, you could have a proprietary mechanism for that. So the question is whether a system not following the Arm specification is allowed. Cheers, -- Julien Grall