WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5] dump-core take 2:

To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5] dump-core take 2:
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 18 Jan 2007 16:54:05 +0800
Cc: John Levon <levon@xxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Dave Anderson <anderson@xxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 18 Jan 2007 00:53:51 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070118083302.GD15865%yamahata@xxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acc622MoXWU+k7+FQoGeQB8DeeA22QAAbKIQ
Thread-topic: [Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5] dump-core take 2:
>From: Isaku Yamahata
>Sent: 2007年1月18日 16:33
>>
>> Should be able to work without these. We need to be able to support
>> ballooning anyway, so it's not as if every E820_RAM region will
>necessarily
>> be entirely populated with memory. What you need is a max_pfn value
>and then
>> iterate 0...max_pfn-1 and try to map each page. If the mapping fails
>then
>> there is no underlying memory. The tools could give a suitable max_pfn
>or we
>> could add a hypercall to get it from Xen.
>
>max_pfn isn't sufficient.
>Memory may be sparse on ia64 so that iterating on [0, max_pfn - 1]
>isn't practical. It would take too long time.
>Mempry map is also necessary to avoid dumping I/O regions of a driver
>domain.
>

Yeah, memory map may be sparse on ia64, but, only at physical level. 
You can always present a compact pseudo physical layout to a 
domain, despite of sparse or not in real physical.:-) BTW, is it possible 
to save memmap into xenstore, so that multiple user components can 
communicate such info directly without xen's intervention?

Thanks,
Kevin

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel