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.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 69FEDC433DF for ; Mon, 15 Jun 2020 19:15:04 +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 329E220739 for ; Mon, 15 Jun 2020 19:15:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FPf+SZgn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 329E220739 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 1jkuYv-0003Q9-Cn; Mon, 15 Jun 2020 19:14:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkuYu-0003Q4-Rw for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 19:14:28 +0000 X-Inumbo-ID: 6e60ee24-af3c-11ea-bb8b-bc764e2007e4 Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6e60ee24-af3c-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 19:14:27 +0000 (UTC) Received: by mail-ed1-x544.google.com with SMTP id t21so12329431edr.12 for ; Mon, 15 Jun 2020 12:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tROvkrjLc9wHL2NHb6pbuOEf92Mjj7qEKcDXhQREEzo=; b=FPf+SZgnBdXkL7xsPfvJd6pSnWUwfgVmITDTr8bV4NLyNFcbfXMq8L81avvnCYy1gr Jrd/wrvyo41gkjzEFDsMGkFKFbp3tqjWLpWMgpTtudfGWxuESRj+Ga1jPueVsLlzei5K bbpjZ5V4MGxpvzJLux7xEBCR2VVPmau6dof1MrEs+4m1OhzBsOFtcXWSA52HiuQAcwpU BS+iqPpcWGPwyoZwGcIODzKdly5a3HmWa+IjIfrk41x6/omKZYQ+9zWcIsSv3Md6IgJw oR0SrCtPv2oiLnoF4xWOoaqbcKKhTqzh/HPVleDqgjR4Q39UBlptrsBMBofel3JRGPI0 DR/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tROvkrjLc9wHL2NHb6pbuOEf92Mjj7qEKcDXhQREEzo=; b=WUQMqW+ZNaA6hQxyfe/WLTr5BCHQS/o1MrOz6+Sj1hxKeAXYvbgbINJ2pXci/ijDif GxC7f+qAnJrPlCbryUWEHXBF73iGM63bfsiojZjVl4EQO1R7qtViz8oi0Tn8WrmecZlh 0GDgmpMxgVWY4Qsv2Rv3vIsQbjOnI3ekCl1IyK6UkKAkhCMgdq/AfRQvDFgnani+HP84 SuuErkuqhmFQBgR8oG3GQdz4PT6jL7WkCCi7tVjzIJ6YBG/4mTBc0Rk1lishOcv86nr9 lzGk/aPLPp+n7Hs51UTjc1XS06iFPNVXFLulJ6q0wg/sJVqRIIxFwqdARm0ttmbWFC2T +8jQ== X-Gm-Message-State: AOAM532P+6USZ2IxqU9UfwvHsCnHDrv3tOFjBA+8GJwPHJxNvxRDfVpT +/O6kLjm4n67uZlSxYHQnxavyIaqk4oGLWhJ5i8= X-Google-Smtp-Source: ABdhPJxQDbQDCl+YK9nOGLMGUCfWD2J/F3oaisbG5jgMI5i6CGhuy0eYWnxDU2frw1hL49Mf8KQNThPZTZ4Rqum7xU8= X-Received: by 2002:a05:6402:1d96:: with SMTP id dk22mr25867754edb.258.1592248466965; Mon, 15 Jun 2020 12:14:26 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: CodeWiz2280 Date: Mon, 15 Jun 2020 15:14:10 -0400 Message-ID: Subject: Re: Keystone Issue To: Julien Grall Content-Type: text/plain; charset="UTF-8" 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: Marc Zyngier , nd , Stefano Stabellini , xen-devel , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 10, 2020 at 5:46 PM Julien Grall wrote: > > Hi Marc, > > On Tue, 9 Jun 2020 at 18:45, Marc Zyngier wrote: > > > I was wondering if you heard about any potential issue with guest EOI > > > not forwarded to the host. This is on TI Keystone (Cortex A-15). > > > > Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Midway > > all run just fine with guest EOI), and GIC-400 is a pretty solid piece > > of kit (it is just sloooooow...). > > > > Thinking of it, you would see something like that if the GIC was seeing > > the writes coming from the guest as secure instead of NS (cue the early > > firmware on XGene that exposed the wrong side of GIC-400). > > Ah, I remember that one. We used to carry an hack in Xen [1] for > X-Gene. Thankfully they fixed the firmware! > > If it is a similar issue, then the firmware path would definitely be > my preference. > > Thank you for the input! Thank you all for the information. If I pull the changes to use the maintenance interrupt for the X-Gene back into the latest build of Xen then my issue with the Edge and Level interrupts is resolved. My ethernet and other devices work fine again for the Keystone in dom0. Are there any concerns over operating this way, meaning with the maintenance interrupt workaround rather than the EOI? Is this safe? 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? 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. > > Cheers, > > [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=50dcb3de603927db2fd87ba09e29c817415aaa44