Re: [Xen-devel] [PATCH 3/8] xen/arm: Implement p2m_type_t as an enum

[Tim Deegan <tim@xxxxxxx>]

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel