From nobody Sun May 5 08:13:12 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1607365850; cv=none; d=zohomail.com; s=zohoarc; b=mLB3qvZe+ExYP8ftvgUUBvsaMDci5hO+A5pMX9sXbPGcPLo9gfNZyYqb8SMDgm4uxftL0nTdQ7DVR31jHj27kYv9xvFpASx+8+Ue2g3DBz3sKMLZhmzTBiORpo/eUIToWsSETeGPGU0ONyp4SD70JVBTgBhu8W79hmE6oOsianU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1607365850; h=Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:Message-ID:Sender:Subject:To; bh=NnUNTnQlKj1fFgpx/X5JRLpJ6Dwse2md2kBNJeqMiDI=; b=SbaOIuLvnzSeCnZ+8Oa3AUgG+ceWYp0yOBZ4xmrefl6eH6LWxqbnr30XAHuaUw5mz6XHr5EYVvr27YE49QR56BUZ5cDcB2ujcgyTzqcUAK5Z010UDHeI+lEUbFArwNt6HWJRdgfdm1xJ6oxG4PdECpitLpCRIuKhvIBQFHOUImw= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 160736585065246.84801096136107; Mon, 7 Dec 2020 10:30:50 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.46912.83111 (Exim 4.92) (envelope-from ) id 1kmKvO-0004sC-Ep; Mon, 07 Dec 2020 18:07:50 +0000 Received: by outflank-mailman (output) from mailman id 46912.83111; Mon, 07 Dec 2020 18:07:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kmKvO-0004s5-Bq; Mon, 07 Dec 2020 18:07:50 +0000 Received: by outflank-mailman (input) for mailman id 46912; Mon, 07 Dec 2020 18:07:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kmKvM-0004s0-BN for xen-devel@lists.xenproject.org; Mon, 07 Dec 2020 18:07:48 +0000 Received: from mailhost.m5p.com (unknown [74.104.188.4]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3ac7b0a4-287c-43b6-922c-4baa9742175d; Mon, 07 Dec 2020 18:07:47 +0000 (UTC) Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPS id 0B7I7UMW033564 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Dec 2020 13:07:36 -0500 (EST) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.15.2/8.15.2/Submit) id 0B7I7TJq033563; Mon, 7 Dec 2020 10:07:29 -0800 (PST) (envelope-from ehem) X-Outflank-Mailman: Message body and most headers restored to incoming version 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" X-Inumbo-ID: 3ac7b0a4-287c-43b6-922c-4baa9742175d Message-Id: <202012071807.0B7I7TJq033563@m5p.com> From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini Cc: Julien Grall Cc: Volodymyr Babchuk Date: Mon, 7 Dec 2020 07:36:11 -0800 Subject: [RFC PATCH] xen/arm: domain_build: Ignore empty memory bank X-Spam-Status: No, score=0.0 required=10.0 tests=KHOP_HELO_FCRDNS autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mattapan.m5p.com Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Previously Xen had stopped processing Device Trees if an empty (size =3D=3D 0) memory bank was found. Commit 5a37207df52066efefe419c677b089a654d37afc changed this behavior to ignore such banks. Unfortunately this means these empty nodes are visible to code which accesses the device trees. Have domain_build also ignore these entries. Signed-off-by: Elliott Mitchell --- Looking at this, I think the problem is likely even larger than this and really needs a proper solution closer to the core of the device-tree code. Likely either all device-tree handling code needs to be audited for ignoring zero-size entries, or the core should take care of these and nothing outside of xen/common/device_tree.c should ever see these (except perhaps to confirm such entries exist as flags). Notably this is the *second* location where zero-size device-tree entries need to be ignored, action might be worthwhile before a third is confirmed. --- xen/arch/arm/domain_build.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index e824ba34b0..0b83384bd3 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1405,6 +1405,11 @@ static int __init handle_device(struct domain *d, st= ruct dt_device_node *dev, { struct map_range_data mr_data =3D { .d =3D d, .p2mt =3D p2mt }; res =3D dt_device_get_address(dev, i, &addr, &size); + + /* Some DT may describe empty bank, ignore them */ + if ( !size ) + continue; + if ( res ) { printk(XENLOG_ERR "Unable to retrieve address %u for %s\n", --=20 --=20 (\___(\___(\______ --=3D> 8-) EHM <=3D-- ______/)___/)___= /) \BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445