From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Rostedt Subject: Re: Tracking "Cannot allocate memory" error in shadow_alloc_p2m_table Date: Fri, 12 Jan 2007 08:05:16 -0500 Message-ID: <45A7878C.5070409@redhat.com> References: <45A4063D.8000207@redhat.com> <20070110113207.GD21843@york.uk.xensource.com> <45A71909.8070300@redhat.com> <20070112110702.GA18763@york.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070112110702.GA18763@york.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: Tim Deegan Cc: Chris Lalancette , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Tim Deegan wrote: > At 00:13 -0500 on 12 Jan (1168560825), Steven Rostedt wrote: >> Why do we need that code, it's using stale data, and updating the shadow >> page tables with a m2p mapping that is from a older domain. > > The domain builder for translated PV guests still populates the physmap > before enabling shadow-translate mode, so needs this init code. Now > that paravirt-ops kernels use proper mmu operations that can probably be > fixed up. > > In the meantime, cset 13326:dc0638bb4628 of xen-unstable should have > stopped it from killing the guest if it finds an entry that's too big. > Is there a way to tell if this is a translated PV guest? I'd rather not do this code at all if it is not needed. We are mapping pages into a guess from junk data. I hate to find out later on that something is missed, and we allow for the guest to have access to memory it should not have. -- Steve