From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacob Gorm Hansen Subject: Re: Is machine_to_phys_mapping a 4MB 'superpage'? Date: Thu, 31 Mar 2005 00:47:52 -0800 Message-ID: <424BB938.805@diku.dk> References: <424B6D94.1080900@diku.dk> <0bed8e482147a6f9f1ca051edf6b03b5@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <0bed8e482147a6f9f1ca051edf6b03b5@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > > On 31 Mar 2005, at 04:25, Jacob Gorm Hansen wrote: > >> The machine_to_phys_mapping table is mapped permanently at 0xFC000000 >> (on x86-32). I would like to experiment with letting the domU map it >> at other locations in its virtual address space, but I suppose that >> for performance it is mapped as a 4MB 'super' page, and as such needs >> special treatment, is this correct? > > > It doesn't *have* to be mapped as a superpage -- control tools don't > when doing suspend/resume, for example. Fixing the permission checking > so that other than domain0 can remap the m2p table shouldn't be very > hard, but I'm not sure what the cleanest method would be. actually I would just like for domUs to be able to map it in different locations, in order to get a little more flexible memory layout. I will probably just try and hack something up for my immediate needs. Jacob