From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 0CDB57803E5 for ; Tue, 7 Nov 2023 10:26:48 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=xq4I5cEuuMbylo0M+MZTCmNzZ6Di4lmI47eIP9KEk2I=; c=relaxed/simple; d=groups.io; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition; s=20140610; t=1699352807; v=1; b=auMdgPIqMJ4GN2V0w8adtd/JGTu2CoYfaJcP2tMyKegVaszp75luzEk0al//mz5QHbqKUKpr GlzjlKlqjKGnybqwf6e8l16oTLu+uAZ0k3RLCNJnjTGf6+5jFKDqFrtmBhP7ZOEvxY9KPPKTYvC or5JDFRriO149AETOY3nKtb4= X-Received: by 127.0.0.2 with SMTP id whdvYY7687511xDK6lHiFQwP; Tue, 07 Nov 2023 02:26:47 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.7225.1699352807028810022 for ; Tue, 07 Nov 2023 02:26:47 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-345-IUYJ76NnNoi2iG95MyHp3A-1; Tue, 07 Nov 2023 05:26:43 -0500 X-MC-Unique: IUYJ76NnNoi2iG95MyHp3A-1 X-Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B3D70811E8F; Tue, 7 Nov 2023 10:26:42 +0000 (UTC) X-Received: from sirius.home.kraxel.org (unknown [10.39.193.119]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 83FF72166B26; Tue, 7 Nov 2023 10:26:42 +0000 (UTC) X-Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 013D81800DDB; Tue, 7 Nov 2023 11:26:40 +0100 (CET) Date: Tue, 7 Nov 2023 11:26:40 +0100 From: "Gerd Hoffmann" To: "Kasireddy, Vivek" Cc: "devel@edk2.groups.io" , "lersek@redhat.com" , Ard Biesheuvel , "Kim, Dongwon" Subject: Re: [edk2-devel] [PATCH v1] OvmfPkg/PlatformInitLib: Don't override user specified PciMmio64Size Message-ID: <6qjwf75ofb3suruqe4dliujih74nxxpw2xyekxwtjrgzwvwd46@4rygctstz472> References: <20231103051519.277323-1-vivek.kasireddy@intel.com> <32d105da-7ccd-9acc-5cea-9a740bcc37f8@redhat.com> <360a4a15-ea24-b59f-d3a0-6ac3d5aef104@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: QM5sgVDvwOPWeBJvSWBqVjHzx7686176AA= Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=auMdgPIq; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io Hi, > > Strictly speaking you don't care that much about the size of the mmio > > window, but where it gets placed. Moving it to the end of the vcpu > > address space is what breaks your use case in case the iommu address > > space happens to be too small for that. > Right, the crux of the problem is indeed the placement of the window > and not the size. Given this, do you see any problem if the mmio window > were to be placed at the lower end of the address space? That might still not work because OVMF scales the window size with the address space. > Or, do you think > ensuring that PhysMemAddressWidth = > automatically via Qemu/OVMF like Laszlo suggested is a better solution > for this problem? The best temporary stop gap IMHO is using -cpu host-phys-bits=on,host-phys-bits-limit= Side note: The qemu master branch has a precompiled seabios version which also does iommu window scaling and will need the same treatment. How to solve that long-term should be discussed on the qemu-devel list. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110835): https://edk2.groups.io/g/devel/message/110835 Mute This Topic: https://groups.io/mt/102359124/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-