From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbEN5-00061L-Ti for qemu-devel@nongnu.org; Tue, 29 Oct 2013 14:50:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VbEN0-0000cb-H0 for qemu-devel@nongnu.org; Tue, 29 Oct 2013 14:50:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbEN0-0000cB-7z for qemu-devel@nongnu.org; Tue, 29 Oct 2013 14:50:26 -0400 Date: Tue, 29 Oct 2013 20:52:42 +0200 From: "Michael S. Tsirkin" Message-ID: <20131029185242.GC20848@redhat.com> References: <1383051455-28188-1-git-send-email-imammedo@redhat.com> <20131029151047.GA20242@redhat.com> <20131029162825.6fe5a0ae@nial.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131029162825.6fe5a0ae@nial.usersys.redhat.com> Subject: Re: [Qemu-devel] [PATCH 0/2 v2] pc: inform SeaBIOS where 64-bit PCI hole begins List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: pbonzini@redhat.com, kraxel@redhat.com, qemu-devel@nongnu.org, aliguori@amazon.com, afaerber@suse.de On Tue, Oct 29, 2013 at 04:28:25PM +0100, Igor Mammedov wrote: > On Tue, 29 Oct 2013 17:10:47 +0200 > "Michael S. Tsirkin" wrote: > > > On Tue, Oct 29, 2013 at 01:57:33PM +0100, Igor Mammedov wrote: > > > * simplify PCI address space mapping into system address space, > > > replacing code duplication in piix/q53 PCs with a helper function > > > > > > * add fw_cfg 'etc/pcimem64-minimum-address' to allow QEMU reserve > > > additional address space before 64-bit PCI hole. Which will be > > > need for reserving memory hotplug region in highmem. > > > SeaBIOS counterpart: http://patchwork.ozlabs.org/patch/283623/ > > > > I'd like to see if we can figure out the migration issue with > > memory layout. > It seems that there isn't migration issue here. Hmm earlier you thought there was - it's ok now? > > Because if we do, and get rid of the separate 64 bit > > region as a concept, exposing the start of this non-existent > > region in FW CFG will make very little sense IMHO. > Well, BIOS have to know where it could start 64-bit BARs mappings > and > telling it explicitly where, looks like a good way to do it. As far as I can tell, BIOS can start any mappings anywhere it wants to as long as they don't overlap anything else. What is has to know is what hardware is there. > > > > > v2: > > > * use negative priority to map PCI address space under RAM memory > > > regions which allows simplify code by removing pci_hole & > > > pci_hole64 memory region aliases > > > > > > Series depends on: > > > "memory: Change MemoryRegion priorities from unsigned to signed: > > > > > > Git tree for testing: > > > https://github.com/imammedo/qemu/commits/pcimem64-minimum-address-v2 > > > > > > Igor Mammedov (1): > > > pc: add 'etc/pcimem64-minimum-address' fw_cfg interface to SeaBIOS > > > > > > Michael S. Tsirkin (1): > > > pc: map PCI address space as catchall region for not mapped addresses > > > > > > hw/i386/pc.c | 28 ++++++++++++++++------------ > > > hw/i386/pc_piix.c | 2 -- > > > hw/pci-host/piix.c | 27 +++++---------------------- > > > hw/pci-host/q35.c | 28 ++++++---------------------- > > > include/hw/i386/pc.h | 15 +++------------ > > > include/hw/pci-host/q35.h | 2 -- > > > 6 files changed, 30 insertions(+), 72 deletions(-)