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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 18/1/07 6:52 am, "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx> wrote:

> Subject: [PATCH 1/5] dump-core take 2: XENMEM_set_memory_map hypercall
> Subject: [PATCH 2/5] dump-core take 2: libxc: xc_domain memmap functions

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.

> Subject: [PATCH 3/5] dump-core take 2: libxc: add xc_domain_tranlate_gpfn()

Why? x86 moved to always mapping HVM memory by GPFN. Can ia64 do the same?

> Subject: [PATCH 4/5] dump-core take 2: hvm builder: tell memory map

Hopefully not needed.

> Subject: [PATCH 5/5] dump-core take 2: elf formatify and added PFN-GMFN table

Shouldn't dump zero pages. Hence we need PFN-GMFN info even for HVM guests
-- absence of PFN-GMFN pair, or GMFN==INVALID_MFN, could represent a RAM
hole more cheaply than 4kB of zeroes. Otherwise PFN=GMFN.

 -- Keir



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