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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 365BFC433E0 for ; Tue, 16 Jun 2020 18:23:52 +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 ECDE8214D8 for ; Tue, 16 Jun 2020 18:23:51 +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="FJckkZRu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ECDE8214D8 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 1jlGFE-0001xD-4i; Tue, 16 Jun 2020 18:23:36 +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 1jlGFC-0001x8-R8 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 18:23:34 +0000 X-Inumbo-ID: 7caee554-affe-11ea-b936-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7caee554-affe-11ea-b936-12813bfff9fa; Tue, 16 Jun 2020 18:23:34 +0000 (UTC) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (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 22AD32098B; Tue, 16 Jun 2020 18:23:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592331813; bh=L+zcAlpK4LLcoh84ilQFXzQsymWz6X1k9LdpJlw13iY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FJckkZRumHrAUk1+W3+921XrTHy+vkfkgMqXbrIBc4n2nuofB1DvFe/Q2A+Pyg/gs cWFSlaFxWUZi1yk48J0R9HbTEkBs8uia5i2D2ijRW589MDaZYvPcvClQB/oTTHJg1b GbeBc0leDYXsfuzDSo7vwpbrvSnENC68EJiUX3Pk= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jlGF9-003W3p-Ls; Tue, 16 Jun 2020 19:23:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 16 Jun 2020 19:23:31 +0100 From: Marc Zyngier To: CodeWiz2280 Subject: Re: Keystone Issue In-Reply-To: References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <4bab90465acfddae5868ce2311bd9889@kernel.org> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: codewiz2280@gmail.com, julien.grall.oss@gmail.com, Bertrand.Marquis@arm.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, nd@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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: xen-devel , nd , Bertrand Marquis , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-16 19:13, CodeWiz2280 wrote: > On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote: >> >> On 2020-06-15 20:14, CodeWiz2280 wrote: >> >> [...] >> >> > Also, the latest linux kernel still has the X-Gene storm distributor >> > address as "0x78010000" in the device tree, which is what the Xen code >> > considers a match with the old firmware. What were the addresses for >> > the device tree supposed to be changed to? >> >> We usually don't care, as the GIC address is provided by the >> bootloader, >> whether via DT or ACPI (this is certainly what happens on Mustang). >> Whatever is still in the kernel tree is just as dead as the platform >> it >> describes. >> >> > Is my understanding >> > correct that there is a different base address required to access the >> > "non-secure" region instead of the "secure" 0x78010000 region? I'm >> > trying to see if there are corresponding different addresses for the >> > keystone K2E, but haven't found them yet in the manuals. >> >> There is no such address. Think of the NS bit as an *address space* >> identifier. >> >> The only reason XGene presents the NS part of the GIC at a different >> address is because XGene is broken enough not to have EL3, hence no >> secure mode. To wire the GIC (and other standard ARM IPs) to the core, >> the designers simply used the CPU NS signal as an address bit. >> >> On your platform, the NS bit does exist. I strongly suppose that it >> isn't wired to the GIC. Please talk to your SoC vendor for whether iot >> is possible to work around this. >> > I do have a question about this out to TI, but at least this method > gives me something to work with in the meantime. I was just looking > to confirm that there wouldn't be any other undesirable side effects > with Dom0 or DomU when using it. Was there an actual FPGA for the > X-Gene that needed to be updated which controlled the GIC access? Or > by firmware do you mean the boot loader (e.g. uboot). Thanks for the > support so far to all. As I said, the specific case of XGene was just a matter of picking the right address, as the NS bit is used as an address bit on this platform. This was possible because this machine doesn't have any form of security. So no HW was changed, no FPGA reprogrammed. Only a firmware table was fixed to point to the right spot. Not even u-boot or EFI was changed. M. -- Jazz is not dead. It just smells funny...