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

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Thu, Jan 18, 2007 at 07:13:17AM +0000, Keir Fraser wrote:
> 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.

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.


> > 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?

IA64 uses GPFN for both domU and HVM.
It is used to just in order to check whether each GPFNs have underlying
memory. Not in order to get MFN.
It can be replaced with trying to map and checking the result,
however I want to know it _before_ dumping pages to create program headers.
Is there any cheaper way than trying to map each PFNs?


> > 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.

I'm not sure I understand.
The posted patch doesn't dump a page which doesn't have underlying memory.
By checking program header's physical address and size
(Elf_Phdr.{p_paddr, p_filesz}), we can know whether a given GPFN is
present or not.

-- 
yamahata

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