RE: [2.6.6 PATCH] Exposing EFI memory map

RE: [2.6.6 PATCH] Exposing EFI memory map

[Tolentino, Matthew E]

> > Interesting. What does ppc64 do with the memmap after that?  
> 
> This doesn't even concern mem_map yet.  The userspace ppc64 hotplug
> tools actually write into the "OpenFirmware" tree from 
> userspace, after
> a hotplug happens.  This is partly because all of the ppc64 hotplug
> operations happen in userspace as it stands now.  

Umm..  my mistake, I meant the memory map passed up by the firmware,
not THE mem_map.  ;-)

> Actually, I was thinking that we'd just allocate the 
> kobjects, and note
> the presence of the memory in the nonlinear phys_section table.  Then,
> when we online it, we can decide where it's mapped, what zone 
> to put it
> in, and where to get the mem_map space from.  I think that approach
> gives the best flexibility. 

Yes, indeed. 

matt

Re: [Lhms-devel] RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Thu, 2004-05-06 at 13:54, Tolentino, Matthew E wrote:
> > > Interesting. What does ppc64 do with the memmap after that?  
> > 
> > This doesn't even concern mem_map yet.  The userspace ppc64 hotplug
> > tools actually write into the "OpenFirmware" tree from 
> > userspace, after
> > a hotplug happens.  This is partly because all of the ppc64 hotplug
> > operations happen in userspace as it stands now.  
> 
> Umm..  my mistake, I meant the memory map passed up by the firmware,
> not THE mem_map.  ;-)

Sorry for the ppc64 tangent, ia64 list people... :)

I'm not quite sure what's it's used for.  I *think* there's a node in
each of the fake OpenFirmware tree directories that exports a magic
resource tag that can identify the memory when it's handed back to the
hypervisor. 

We need this number exported to userspace, because we basically make the
hypervisor calls from there.  It's safe to say that I'd prefer this
method be revised at some point in the future.  

-- Dave