[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/8] xen/arm: Implement p2m_type_t as an enum
B11;rgb:0000/0000/0000At 16:39 +0000 on 05 Dec (1386257979), Ian Campbell wrote: > On Thu, 2013-12-05 at 17:31 +0100, Tim Deegan wrote: > > 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. > > I think we avoid all those pitfalls on arm right now, so probably > invalid == P==0b0,AVAIL=0b0000 makes sense? Sure. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |