From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [HYBRID] : mapping IO mems in the EPT Date: Mon, 18 Jun 2012 14:35:57 -0400 Message-ID: <20120618183557.GA28050@phenom.dumpdata.com> References: <20120614184338.43fb879b@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: "Xen-devel@lists.xensource.com" , Ian Campbell List-Id: xen-devel@lists.xenproject.org On Fri, Jun 15, 2012 at 12:02:19PM +0100, Stefano Stabellini wrote: > On Fri, 15 Jun 2012, Mukesh Rathor wrote: > > Hi guys, > > > > During my refresh to latest linux, I noticed, direct mapping of all > > non-RAM pages in xen_set_identity_and_release(). I currently don't map > > all at front, but as needed looking at the PAGE_IO bit in the pte. One PV doesn't look at that all the time either. The P2M tree code has a couple of leafs, that if they have IDENTITY_FRAME_BIT set it will automatically stick _PAGE_IOMAP on the PTE. > > result of that is minor change to common code macro: > > > > __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE) to > > to __set_fixmap(idx, phys, PAGE_KERNEL_IO_NOCACHE) I am really wafling on that. Jeremy posted a patch some time ago to x86 folks that would do something similar (I can't remember the details), but hpa said - why don't you just consult the E820. That is where the IDENTITY_FRAME_BIT thing in the P2M tree came about. It could probably be implemented for your cases using ranges. Similary to how Xen permits/disallows certain IO regions to be touched. Would something like that potentially allow you do something like this: xen_hybrid_pte() phys_addr_t phys = pte.pte & PTE_PFN_MASK if (phys .. within ranges) pte |= _PAGE_IOMAP; return pte; > > > > > > To avoid this change, and keep all my changes limited to xen files only, > > I thought I could just map the entire non-ram pages up front too. But > > I am concerned the EPT may grow too large? Specially, when we get to > > *really* large NUMA boxes. What do you guys think? Should I worry about > > it? Would NUMA boxes have more than 1GB of E820 non-RAM regions? I can see them having gobs of RAM regions, but non-RAM regions? > > I would map them all up front and worry about it later. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel