From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.32137.1644833899126512574 for ; Mon, 14 Feb 2022 02:18:24 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dnR+uGt4; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644833898; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ob28f3jKtBkQrkZWld7K3a/8d+cZQt6wI0jdv1vyPl0=; b=dnR+uGt42iDEhs1nYdVHjDqwZDL6d9P014bgiBbASsb0HyYZ+XMowCPBDkf0C3Av5tf5Hh 1SOqV92jmzp6LpLVPr28et/IOdFSPmF5oZs1RcldrP3UGM49Gw3AeUcSeXUHCErOuFFdNx bl1x3DF/dA7c3NjUjXpWi+J/cMZ11no= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-402-O0Ss9tBRP462HGgLsK4FiQ-1; Mon, 14 Feb 2022 05:18:14 -0500 X-MC-Unique: O0Ss9tBRP462HGgLsK4FiQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 04E4B2F25; Mon, 14 Feb 2022 10:18:13 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.34]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A04676F125; Mon, 14 Feb 2022 10:18:12 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id DDFD41800091; Mon, 14 Feb 2022 11:18:10 +0100 (CET) Date: Mon, 14 Feb 2022 11:18:10 +0100 From: "Gerd Hoffmann" To: "Ojeda Leon, Nicolas" Cc: "devel@edk2.groups.io" , "Gupta, Atul" , "Graf (AWS), Alexander" Subject: Re: [PATCH v4 7/8] PciHostBridgeDxe: Extend service to get base addresses before allocation Message-ID: <20220214101810.xiievg2xi5ttgcam@sirius.home.kraxel.org> References: <68baf235a1b6fe824424f874c6d6f5a015676717.1643919691.git.ncoleon@amazon.com> <20220204083602.w2r7c6hwj423a6bm@sirius.home.kraxel.org> <51b4eb6b2c1049f29e21dd6a208e6965@EX13D49EUC003.ant.amazon.com> MIME-Version: 1.0 In-Reply-To: <51b4eb6b2c1049f29e21dd6a208e6965@EX13D49EUC003.ant.amazon.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 04, 2022 at 09:17:48AM +0000, Ojeda Leon, Nicolas wrote: > Hi Gerd, > > > Hmm, so you are hiding the #define here to avoid updating Protocol/PciHostBridgeResourceAllocation.h ... > > > > I suspect if this can't be implemented in the pci enumerator alone there is just no way around actually extending uefi protocols. But it's also not fully clear to me why you need this new "partial" state. > > Wouldn't you know either nothing or both base + size for a resource? > > > > Yes you are right, the current status is we have nothing and after the > resources are allocated we have base and size. However, the allocation > happens after CreateResourceMap is called, this function is the one > that iterates over all resources of all devices under a root bridges > and places them in a root bridge relative offset to then calculate the > length of the resources required for that specific root bridge. For > the pre-populated BARs I retrieve the Base Address of the Root Bridge > before placing the resources at the root bridge relative offset so > that I can translate the BAR address (set by the host) into an offset. > That's why I created this patch to retrieve only the base address > before the root bridge resource map is created, submitted and > allocated. Hmm, nasty init order issue. No good idea offhand. Have you tried to exclude the pre-populated BARs from the host bridge windows communicated to the edk2 pci core? The pci enumerator should not create overlapping pci bar assignment then. But it might very well be that this only shifts the problem to another place ... take care, Gerd