From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH 3/8] xen/arm: Implement p2m_type_t as an enum Date: Thu, 5 Dec 2013 17:31:50 +0100 Message-ID: <20131205163150.GC2093@deinos.phlegethon.org> References: <1386258131-755-1-git-send-email-julien.grall@linaro.org> <1386258131-755-4-git-send-email-julien.grall@linaro.org> <1386258750.20047.84.camel@kazak.uk.xensource.com> <20131205160737.GA2093@deinos.phlegethon.org> <1386260358.20047.105.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VobqF-0000zS-OD for xen-devel@lists.xenproject.org; Thu, 05 Dec 2013 16:31:55 +0000 Content-Disposition: inline In-Reply-To: <1386260358.20047.105.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xenproject.org, Julien Grall , stefano.stabellini@citrix.com, patches@linaro.org List-Id: xen-devel@lists.xenproject.org At 16:19 +0000 on 05 Dec (1386256758), Ian Campbell wrote: > On Thu, 2013-12-05 at 17:07 +0100, Tim Deegan wrote: > > At 15:52 +0000 on 05 Dec (1386255150), Ian Campbell wrote: > > > On Thu, 2013-12-05 at 15:42 +0000, Julien Grall wrote: > > > > Until now, Xen doesn't know the type of the page (ram, foreign page, mmio,...). > > > > Introduce p2m_type_t with basic types: > > > > - p2m_invalid: Nothing is mapped here > > > > > > Do we really need this? Is it not equivalent to not setting the present > > > bit? I see x86 has the same type though -- Tim can you explain why. > > > > There are other not-present types on x86: PoD, paged-out, emulated-MMIO. > > This means not Present doesn't imply invalid, I see. Even if we don't > currently have such types I can see how this makes sense. In theory when > we get short of bits we could consider the P bit one of the type bits, > which would give us 16 present and 16 not-present types. Overkill for > now I expect. > > Is it ever the case that an actual p2m entry contains the p2m_invalid > bit pattern Yes, IIRC if an existing entry is removed, it's replaced with an explicit invalid entry. It used to be the case that inclid was type 0 so by default all uninitialised entries were invalid too, but ram_rw had to be type 0 (becasue of an inconvenient interacion with AMD IOMMUs). For added confusion on x86 we still have the legacy rule that invalid entries are reported as mmio_dm, because the default path is to ask qemu. Tim.