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.19946.1664946123327402883 for ; Tue, 04 Oct 2022 22:02:03 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CtQ9qHeB; 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=1664946122; 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=GI0p/et6O3dNAG2MitDhZHVoQsTt6BdNQ91GR1favF0=; b=CtQ9qHeBoFNBaws/M17MGS14/eEJ4IzYqSw5KBRLlljoBWbbVP/Xog2ev2s+dDKzgYiTCv EJofZBadiEIWBZ1bghSdbL/F2uTrr03v7IRqKlLin7WoTHtTpbOkZzOn+PQzcKfLkdWhRj DNsDe7TvqJqHNV221ztI+1drglHxlmU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-622-QqElwcc1MQK6SUNnRSQZMA-1; Wed, 05 Oct 2022 01:01:58 -0400 X-MC-Unique: QqElwcc1MQK6SUNnRSQZMA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1971518E0056; Wed, 5 Oct 2022 05:01:58 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.173]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DB53BC15BB4; Wed, 5 Oct 2022 05:01:57 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 8168E180039D; Wed, 5 Oct 2022 07:01:56 +0200 (CEST) Date: Wed, 5 Oct 2022 07:01:56 +0200 From: "Gerd Hoffmann" To: Laszlo Ersek Cc: devel@edk2.groups.io, Jordan Justen , Pawel Polawski , Jiewen Yao , Oliver Steffen , Ard Biesheuvel Subject: Re: [PATCH v2 4/4] OvmfPkg/PciHotPlugInitDxe: reserve more mmio space Message-ID: <20221005050156.y5vcmelhtnbwgcbt@sirius.home.kraxel.org> References: <20221004134728.55499-1-kraxel@redhat.com> <20221004134728.55499-5-kraxel@redhat.com> <6e33ffa4-4f06-c993-6ceb-474805e28cac@redhat.com> MIME-Version: 1.0 In-Reply-To: <6e33ffa4-4f06-c993-6ceb-474805e28cac@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Oct 04, 2022 at 05:57:46PM +0200, Laszlo Ersek wrote: > On 10/04/22 15:47, Gerd Hoffmann wrote: > > In case the 64-bit pci mmio window is larger than the default size > > of 32G be generous and hand out larger chunks of address space for > > prefetchable mmio bridge windows. > > + SetMmioPadding ( > > + --FirstResource, > > + TRUE, > > + FALSE, > > + (UINTN)HighBitSetRoundUp64 (RShiftU64 (Pci64Size, 8)) > > + ); > Looks good to me, thanks; I'm just missing the rationale on the > RShiftU64() call. Please elaborate. Cover letter explains this a bit. The idea is to scale things up with the available address space. Patch #3 does that for the 64-bit pci mmio window. This patch does the same for the bridge windows, leveraging the patch #3 calculations by looking at PcdPciMmio64Size. The shift by 8 assigns 1/256 of the total mmio window size to each bridge. The '8' is just pulled out of thin air. Looks reasonable to me, in case it turns out it is not we can adjust that in the future. take care, Gerd