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 71CAE7803CC for ; Mon, 6 Nov 2023 11:48:37 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=D97EYGfzCyzLaqTuL8MkyvFtnzFnBNMVRepj+Ac6KBs=; 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=1699271316; v=1; b=gc+Jq4VIlBozW987GLvdmNsdjtUk4mly4EEfdd1FPk/QwdAO7trJElW+hxGeD3xe7aS5iZSy myE9WagdCLm2O093i14rCg9tzQKrL87+rCFYeV4VTs2r5V+HMjiflne3c8G2Lr2AAqujto+yA/b 6oSKjqxkpJ4pYK52CSxAOQAQ= X-Received: by 127.0.0.2 with SMTP id pIC6YY7687511xoU1LEA5YR0; Mon, 06 Nov 2023 03:48:36 -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.51836.1699271315372226028 for ; Mon, 06 Nov 2023 03:48:35 -0800 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-553-H0nSmNRjNwm8woJ5bZbW1A-1; Mon, 06 Nov 2023 06:47:55 -0500 X-MC-Unique: H0nSmNRjNwm8woJ5bZbW1A-1 X-Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (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 61AB628237C6; Mon, 6 Nov 2023 11:47:55 +0000 (UTC) X-Received: from sirius.home.kraxel.org (unknown [10.39.193.119]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3201C143; Mon, 6 Nov 2023 11:47:55 +0000 (UTC) X-Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id D851E18012D3; Mon, 6 Nov 2023 12:47:53 +0100 (CET) Date: Mon, 6 Nov 2023 12:47:53 +0100 From: "Gerd Hoffmann" To: devel@edk2.groups.io, lersek@redhat.com Cc: vivek.kasireddy@intel.com, Ard Biesheuvel , Dongwon Kim Subject: Re: [edk2-devel] [PATCH v1] OvmfPkg/PlatformInitLib: Don't override user specified PciMmio64Size Message-ID: 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: <360a4a15-ea24-b59f-d3a0-6ac3d5aef104@redhat.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 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: 7Ur1mfrHT7005Qw2UjOzcSxCx7686176AA= 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=gc+Jq4VI; 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, > > I agree that the proposed patch can function as a stop-gap, but the QEMU > > command line hack is already a stop-gap. And for the long term, this > > patch is not good enough. We should enhance the dynamic sizing, now that > > Gerd has put it into place. > > ... I do agree however that the current behavior is strange -- the user > specifies an explicit fw_cfg knob for OVMF, and OVMF ignores it (for > whatever reason). > > I'd like to know what Gerd thinks of this. The current code effectively considers the user-specified PciMmio64Size as a lower limit, it will never be smaller but might be larger in case OVMF figures it has enough space. Being more strict here and use the user-specified PciMmio64Size as-is no matter what is fine with me. The independent but related question is where the window should be placed in case we have a valid vcpu address space size and PciMmio64Size specified by the user. > (b) there were a promise to enhance QEMU and OVMF as I suggest above. Fully agree. We should explicitly communicate requirements (in this case: iommu address space size) instead of depending on side effects of unrelated config options. 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. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110748): https://edk2.groups.io/g/devel/message/110748 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] -=-=-=-=-=-=-=-=-=-=-=-