From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5IK2-0001yE-GX for qemu-devel@nongnu.org; Sun, 18 Sep 2011 10:26:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5IK1-0001gp-Gv for qemu-devel@nongnu.org; Sun, 18 Sep 2011 10:26:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37647) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5IK1-0001ga-8S for qemu-devel@nongnu.org; Sun, 18 Sep 2011 10:26:17 -0400 Message-ID: <4E75FF82.6030202@redhat.com> Date: Sun, 18 Sep 2011 17:26:10 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E75F7F3.6070500@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] memory: simple memory tree printer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel On 09/18/2011 05:07 PM, Blue Swirl wrote: > On Sun, Sep 18, 2011 at 1:53 PM, Avi Kivity wrote: > > On 09/17/2011 10:27 PM, Blue Swirl wrote: > >> > >> Add a monitor command 'info mtree' to show the memory hierarchy > >> much like /proc/iomem in Linux. > >> > >> > > > > Still missing alias support. PCI would be invisible on a PC (or any machine > > which has PCI holes implemented properly). > > Yes, that annoyed me too when debugging the PPC patch. But how should > that look like? Consider for example that in the PPC case, range 0 to > 0x80000000 is RAM from CPU point of view but only PCI MMIO space when > looking after the PCI bridge. I/O shouldn't need separate handling if > the CPU does not have PIO instructions, but instead PIO space is > mapped as MMIO as on Sparc64 and PPC. I/O should be visible there. Have some notation for a reference. Example for PC: Memory: 00000000-7fffffffffffffff system-memory container 00000000-0009ffff alias @ram 00000000-0009ffff 000a0000-000bffff alias @pci 000a0000-000bffff ... e0000000-ffffffff alias @pci e0000000-ffffffff pci: 00000000-ffffffffff pci container 000a0000-000bffff alias @vgam 00000000-0001ffff e0000000-e1ffffff alias @vram 00000000-01ffffff e2000000-e2001000 e1000-mmio vram: 00000000-01ffffff vram ram (each time you encounter a new alias target, add it to the print queue, it should work itself out naturally) > > > Maybe we need to dump both the memory tree and the flat view - the memory > > tree for the logical hierarchy and the flat view to see what actually > > happens (I have an address, where does it go?) > > I have some trouble thinking about how to print fully converted, > per-CPU memory trees. Also, if the memory API is fully embraced and > extended to handle DMA and IOMMUs, each device could have a different > view on the system memory. Perhaps the tool should take a device ID > (also CPU ID) as a parameter to give it a starting point. The possibilities are endless. -- error compiling committee.c: too many arguments to function