From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: [PATCH]: Allow tools to map arbitrarily large machphys_mfn_list on 32bit dom0 Date: Mon, 14 Mar 2011 16:54:27 +0000 Message-ID: References: <1300120438.17339.2202.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1300120438.17339.2202.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell , Jan Beulich Cc: Tim Deegan , Xen Devel , Gianni Tedesco List-Id: xen-devel@lists.xenproject.org On 14/03/2011 16:33, "Ian Campbell" wrote: >> But RDWR_COMPAT_MPT_VIRT_END still doesn't necessarily >> cover all of the memory the machine may have (after all the >> range is way smaller than RDWR_MPT_VIRT_{START,END}. > > It's 1GB which is enough to cover 1TB of host memory, which AFAIK is all > we support these days. It certainly buys us time compared with currently > failing at 160GB. > >> If that's the goal, then the patch as presented isn't suitable, >> as there's not event a compat table set up for all of the >> memory. > > paging_init seems to do the right thing and setup the compat M2P up to a > maximum of RDWR_COMPAT_MPT_VIRT_END. > >> I'd say the tools then need to have access to the >> native table, reading 64-bit MFNs from it (since, with MFN >> compression, we can exceed 32-bits). > > That's another option I guess. It's not really an option for 4.1.0. Can we at least agree that this is an improvement for now, and in time for 4.1.0? -- Keir