From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4140B211E0118 for ; Wed, 20 Mar 2019 04:15:38 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4933830833C2; Wed, 20 Mar 2019 11:15:37 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-91.rdu2.redhat.com [10.10.120.91]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9062410021B1; Wed, 20 Mar 2019 11:15:35 +0000 (UTC) To: Anthony PERARD , Igor Druzhinin Cc: edk2-devel@lists.01.org, jordan.l.justen@intel.com, ard.biesheuvel@linaro.org, julien.grall@arm.com, xen-devel@lists.xenproject.org References: <1551876056-28223-1-git-send-email-igor.druzhinin@citrix.com> <1551876056-28223-2-git-send-email-igor.druzhinin@citrix.com> <20190314174121.GB11621@perard.uk.xensource.com> <096a1987-a898-9896-8ffd-9fc8512e25f6@citrix.com> <20190319140319.GJ11621@perard.uk.xensource.com> From: Laszlo Ersek Message-ID: Date: Wed, 20 Mar 2019 12:15:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190319140319.GJ11621@perard.uk.xensource.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Wed, 20 Mar 2019 11:15:37 +0000 (UTC) Subject: Re: [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 11:15:39 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 03/19/19 15:03, Anthony PERARD wrote: > On Thu, Mar 14, 2019 at 07:45:56PM +0000, Igor Druzhinin wrote: >> On 14/03/2019 17:41, Anthony PERARD wrote: >>> Hi, >>> >>> On Wed, Mar 06, 2019 at 12:40:54PM +0000, Igor Druzhinin wrote: >>>> This aperture doesn't exist in OVMF and trying to use it causes >>> >>> I'm trying to understand what you mean by writing "doesn't exist in >>> OVMF". Are prefetchable BAR not handled by ScanForRootBridges() ? >>> Or is it the emulation of the config space that isn't correct? >>> Maybe QEMU should lies about a BAR been prefetchable? >> >> The problem here is: hvmloader places BARs initially disregarding >> prefetchable bit in an arbitrary order because essentially there is only >> 1 aperture for the host bridge in emulated system under Xen (and KVM as >> well). In PcatPciRootBridgeParseBars() we construct apertures for high >> level OVMF code by reading the BAR placement information after >> hvmloader. It often appears that there are prefetchable and >> non-prefetchable BARs coexist with each other and make prefetchable and >> non-prefetchable apertures overlap. This eventually triggers an >> assertion in high level OVMF code because that shouldn't happen. > > Thanks for the explanation. Could you add it to the patch description? > >> OVMF for KVM is not using prefetchable BAR at all - see >> PciHostBridgeGetRootBridges() in which it passes mNonExistAperture dummy >> object to high level code. I think it's wrong to construct a >> prefetchable aperture for Xen and this code should be removed as it's >> done for QEMU-KVM. Do you think this patch needs to do that? > > It would be nice to remove the code that isn't useful so feel free to do > it and/or keep the current patch with the description updated. Right -- I'd like to add one keyword here, for background: EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM. (It's documented in both edk2 [MdePkg/Include/Protocol/PciHostBridgeResourceAllocation.h] and the PI spec [EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL.GetAllocAttributes()].) Thanks Laszlo