From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFnqZ-0001nd-AV for qemu-devel@nongnu.org; Tue, 18 Feb 2014 11:48:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFnqT-00057R-AW for qemu-devel@nongnu.org; Tue, 18 Feb 2014 11:48:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62324) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFnqT-00057M-2X for qemu-devel@nongnu.org; Tue, 18 Feb 2014 11:48:33 -0500 Date: Tue, 18 Feb 2014 17:48:27 +0100 From: Igor Mammedov Message-ID: <20140218174827.2582af5e@nial.usersys.redhat.com> In-Reply-To: <1392625760.26953.9.camel@nilsson.home.kraxel.org> References: <1391777496-3882-1-git-send-email-imammedo@redhat.com> <1392625760.26953.9.camel@nilsson.home.kraxel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/9] generate dynamic _CRS for motherboard resources List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org, anthony@codemonkey.ws, mst@redhat.com On Mon, 17 Feb 2014 09:29:20 +0100 Gerd Hoffmann wrote: > On Fr, 2014-02-07 at 13:51 +0100, Igor Mammedov wrote: > > Since introduction of PCIHP, it became problematic to > > punch hole in PCI0._CRS statically since PCI hotplug > > region size became runtime changeable. > > > > So replace static hole punching with dynamically consumed > > resources in a child device on PCI0 bus. i.e generate > > PNP0C02 device as a child of PCI0 bus at runtime and > > consume GPE0, PCI/CPU hotplug IO resources in it instead > > of punching holes in static PCI0._CRS. > > Nice. Can you try to do that for the mmconf xbar in memory space too > while being at it? If I manage to convince mst in using macro approach. PS: Although his build_append_foo() functions have tremendously improved dynamic AML generation (made it much less error-prone), the current acpi-build.c becomes harder to read (just look at new pcihp parts). So I'm arguing in favor of more simple/intuitive API approach even if it uses macros (I'm really not fun of it, but result is much clear/maintainable code). > > cheers, > Gerd > >