From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vb7lT-0007GW-V8 for qemu-devel@nongnu.org; Tue, 29 Oct 2013 07:47:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vb7lL-00053y-0e for qemu-devel@nongnu.org; Tue, 29 Oct 2013 07:47:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25471) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vb7lK-00052m-PZ for qemu-devel@nongnu.org; Tue, 29 Oct 2013 07:47:06 -0400 Date: Tue, 29 Oct 2013 13:49:52 +0200 From: "Michael S. Tsirkin" Message-ID: <20131029114952.GB18289@redhat.com> References: <1381913354-8815-1-git-send-email-imammedo@redhat.com> <20131016092045.GA21233@redhat.com> <20131029110856.3e5ead43@nial.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131029110856.3e5ead43@nial.usersys.redhat.com> Subject: Re: [Qemu-devel] [PATCH 0/4] pc: inform SeaBIOS where 64-bit PCI hole start and PCI mappings cleanup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: armbru@redhat.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, kraxel@redhat.com, aliguori@amazon.com, pbonzini@redhat.com, afaerber@suse.de On Tue, Oct 29, 2013 at 11:08:56AM +0100, Igor Mammedov wrote: > On Wed, 16 Oct 2013 12:20:45 +0300 > "Michael S. Tsirkin" wrote: > > > On Wed, Oct 16, 2013 at 10:49:10AM +0200, Igor Mammedov wrote: > > > * simplify PCI address space mapping into system address space, > > > replacing code duplication in piix/q53 PCs with helper function > > > > I think this does not go far enough. > > > > I was always wondering about PCI hole in QEMU. > > Some real PCs have a "PCI hole" where PCI > > masks real memory, but PIIX does not do this, > > instead PCI is whenever RAM does not mask it. > > > > So it looks like the hole concept is a left-over > > from when we didn't have priorities in the memory API. > > How about we remove them? > > See patch below. > > I did a quick boot test and it seems to work, of course > > it needs much more testing. > > It's on top of Marcel's series adding negative priorities, > > so works on top of the acpi branch or the pci branch. > I have done quite thorough testing and it works well except of > one caveat, it breaks migration due to different memory regions > layout. > > So we'll have to keep an old aliasing scheme at least for old > machine types. Having that in mind do we still want to add > an extra implementation as you suggested? Sorry I didn't answer this question. I think it's a bug - PCI hole should not affect migration.