From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlLpV-0001L7-3j for qemu-devel@nongnu.org; Mon, 25 Jul 2011 10:08:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QlLpU-0006De-AJ for qemu-devel@nongnu.org; Mon, 25 Jul 2011 10:08:21 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:62533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlLpU-0006DZ-6G for qemu-devel@nongnu.org; Mon, 25 Jul 2011 10:08:20 -0400 Received: by yxt3 with SMTP id 3so2727186yxt.4 for ; Mon, 25 Jul 2011 07:08:19 -0700 (PDT) Message-ID: <4E2D78D1.8060105@codemonkey.ws> Date: Mon, 25 Jul 2011 09:08:17 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1311180636-17012-1-git-send-email-avi@redhat.com> <1311180636-17012-87-git-send-email-avi@redhat.com> <4E2D6A97.9050606@codemonkey.ws> <4E2D6C45.5030308@redhat.com> <20110725131728.GD4404@redhat.com> <4E2D6F6C.5070301@redhat.com> <4E2D702F.6010400@redhat.com> <20110725133558.GH4404@redhat.com> <4E2D71F1.4090509@redhat.com> <4E2D73F3.8060507@codemonkey.ws> <4E2D7825.9030200@redhat.com> In-Reply-To: <4E2D7825.9030200@redhat.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org, Gleb Natapov , kvm@vger.kernel.org On 07/25/2011 09:05 AM, Avi Kivity wrote: > On 07/25/2011 04:47 PM, Anthony Liguori wrote: >> On 07/25/2011 08:38 AM, Avi Kivity wrote: >>> On 07/25/2011 04:35 PM, Gleb Natapov wrote: >>>> > >>>> > That's the ISA TOM (15MB hole and friends). >>>> > >>>> Correct. What about: >>>> 3.2.19. DRB[0:7] DRAM ROW BOUNDARY REGISTERS >>>> >>>> from 440fx spec? >>>> >>> >>> Maybe. But we can't use that, since it ignores address line 31. >>> >>> (440fx supports only 1GB RAM, and we're ignoring that) >> >> What are we trying to do? >> >> Can't we just register highest RAM address under 4G to 4G as PCI >> memory and call it a day? >> >> Do we really need a guest visible register to do this? > > Why not use 3.5GB and call it a day? It's safer for memory hotplug, if > we ever get it. > > The guest will never put a PCI BAR below that anyway. My entire concern is that they will. We're not just talking about Windows or Linux here, but any odd DOS application that's smart enough to switch into 32-bit mode, bootloaders, etc. It's a significant behaviorial change that goes against the spec for no obviously good reason. Even if we supported hot plug, we could easily just hot plug above the 4GB mark. Regards, Anthony Liguori >