From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes Date: Mon, 25 Jul 2011 16:50:52 +0300 Message-ID: <20110725135052.GI4404@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60995 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751178Ab1GYNu4 (ORCPT ); Mon, 25 Jul 2011 09:50:56 -0400 Content-Disposition: inline In-Reply-To: <4E2D73F3.8060507@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Jul 25, 2011 at 08:47:31AM -0500, 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? > I just tried to answer Avi's question about TOM register. > Can't we just register highest RAM address under 4G to 4G as PCI > memory and call it a day? > It is good idea to emulate existing functionality as close as possible, but if existing functionality does not satisfy us (like in our case) then yes, we can. > Do we really need a guest visible register to do this? > > Regards, > > Anthony Liguori > > > -- Gleb. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlLYh-0006gN-0f for qemu-devel@nongnu.org; Mon, 25 Jul 2011 09:51:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QlLYe-00005K-RM for qemu-devel@nongnu.org; Mon, 25 Jul 2011 09:50:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2124) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlLYd-0008VL-U6 for qemu-devel@nongnu.org; Mon, 25 Jul 2011 09:50:56 -0400 Date: Mon, 25 Jul 2011 16:50:52 +0300 From: Gleb Natapov Message-ID: <20110725135052.GI4404@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E2D73F3.8060507@codemonkey.ws> 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: Anthony Liguori Cc: Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org On Mon, Jul 25, 2011 at 08:47:31AM -0500, 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? > I just tried to answer Avi's question about TOM register. > Can't we just register highest RAM address under 4G to 4G as PCI > memory and call it a day? > It is good idea to emulate existing functionality as close as possible, but if existing functionality does not satisfy us (like in our case) then yes, we can. > Do we really need a guest visible register to do this? > > Regards, > > Anthony Liguori > > > -- Gleb.