From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: xc_get_pfn_list() creates broken core files Date: Thu, 23 Nov 2006 23:33:59 +0000 Message-ID: References: <20061123205257.GA4041@totally.trollied.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20061123205257.GA4041@totally.trollied.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: John Levon , Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 23/11/06 8:52 pm, "John Levon" wrote: > Use the guest's own p2m table instead of xc_get_pfn_list(), which cannot > handle PFNs with no MFN. > Dump a zeroed page for PFNs with no MFN. > Clearly deprecate xc_get_pfn_list(). > Do not include a P2M table with HVM domains. > Refuse to dump HVM until we can map its pages with PFNs. > > Signed-off-by: John Levon Rather than dump zero pages we could save a PFN-GMFN pair for each dumped page. These can all go at the start of the core file in place of the p2m. The dumped pages will then be in order of the PFN-GMFN pairs. For a PV guest PFN=pseudophys, GMFN=machine (real). For an HVM guest PFN=GMFN=pseudophys. Finding max_pfn for a HVM guest is a bit tricky right now: we could add a hypercall to read it out from Xen, or we could have Xen maintain the shared_info max_pfn field. -- Keir