From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47861) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj3Hb-0003R4-0r for qemu-devel@nongnu.org; Wed, 20 Nov 2013 03:37:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vj3HU-0004pp-V5 for qemu-devel@nongnu.org; Wed, 20 Nov 2013 03:37:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29116) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj3HU-0004pj-Ks for qemu-devel@nongnu.org; Wed, 20 Nov 2013 03:37:04 -0500 Message-ID: <1384936610.2005.52.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Wed, 20 Nov 2013 09:36:50 +0100 In-Reply-To: <20131119220306.GF15004@redhat.com> References: <1384269110-23613-1-git-send-email-lersek@redhat.com> <528AA407.8070503@redhat.com> <1384851266.16718.162.camel@nilsson.home.kraxel.org> <528B5A2B.3060100@redhat.com> <20131119211312.GD15004@redhat.com> <528BDA7A.9090701@redhat.com> <20131119220306.GF15004@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [edk2] [edk2 PATCH 0/1] OvmfPkg: grab ACPI tables from QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Wei Liu , alex.williamson@redhat.com, edk2-devel@lists.sourceforge.net, Laszlo Ersek , qemu-devel@nongnu.org Hi, > > If you simply relax (drop) the stage-wise hole-setting, that will at > > best create a situation where OVMF and qemu duplicate the logic. This > > info needs to be passed down to OVMF (maybe it already is, somewhere in > > fw_cfg!), in some form that's more approachable than an ACPI table. (We > > absolutely don't want to parse ACPI (AML) in OVMF.) No need to parse aml. The acpi tables are not fixed, qemu tweaks them according to the hardware programming done by the guest. > Two possible fixes, both of them in QEMU: > 1. declare all available regions (that resolve to PCI) in _CRS > 2. detect where did guest put PCI devices and declare the result in _CRS > > 2 is exactly what we did for 64 bit BARs. Well, it's actually a mix, isn't it? 64bit window base address is derived from guest pci bar mapping, 64bit window size is configurable to leave room for hotplug (or maybe that is the future plan still ...). I think we should simply declare end-of-lowram -> ioapic base as 32bit window. Looking at the pci bar locations programmed by the guest will only make this smaller, leaving less space for hotplug, for no good reason. > The only issue I worry about is MTRRs. > Maybe we are lucky and they do not matter for KVM. I think they are largely cosmetic in virtual machines. And if ovmf wants use 0xa000000+ as pci io window it still has the option to create two mtrr entries to cover the region (one 512m @ 0xa0000000 and one 1G @ 0xc0000000). cheers, Gerd