Re: [XenPPC] [PATCH] Move lots of memory logic earlier

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

On Jan 10, 2007, at 12:43 PM, Hollis Blanchard wrote:

> On Tue, 2007-01-09 at 12:24 -0500, Jimi Xenidis wrote:
> > > We have currently have three page allocators. The first is PPC-
> > > specific,
> > > and it includes the Xen image, RTAS, and our copy of the Open
> > Firmware
> > > device tree.
> > More precisely, it is OF-specific and exists because we cannot trust
> > the "claim" OF-method, so really it is more of a workaround.
> You say we can't trust "claim",
hmm, "trust" implies a lot, I guess...

> but a) we trust "available" properties,
We trust "available" to have correct information but not to be  
complete, or up to date.
> and b) we trust the return code from "claim".
Excellent point, we trust the "claim" is implemented and that it  
_may_ object if the address conflicts.  If "claim" is not implemented  
_at_all_ then the current code would interpret it as rejecting all  
addresses and we would be screwed.
> So the only thing you could mean is that we don't trust that "claims"
> will be reflected in the "available" properties. Is that what you  
> mean?
> Where have we seen that?
IIRC:
PIBS:
 - does not implement "available", but may in the next release (so  
I'm told)
 - "claim" will tell you only about PIBS conflicts
   - will not tell you about conflicts with other claims or loaded  
images
SLOF:
 - does implement, but does not update "available", though recent  
resions might
 - "claim" will only tell you about conflicts its self
   - will not tell you about conflicts with other claims or loaded  
images
GFW: does everything as spec'ed
Apple: does everything as spec'ed

-JX





_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel