[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[XenPPC] FYI: more "of_handler" firmware notes



A while back I mentioned some of the issues around our "of_handler" directory; 
the in-domain Open Firmware client interface that makes Xen hcalls. One of 
the options was to drop it entirely, since we could have Xen provide a device 
tree in Linux's "flattened" format. However, I think we do want to keep it 
long-term, especially since it would be poor form to lock out non-Linux 
guests.

To solve the immediate issue, I copied some of rhype's lib code into 
of_handler, removing our dependence on xen/common/*. I think it's reasonable 
to have our firmware buildable standalone, like the Bochs "vgabios" or 
whatever the Xen HVM guys are using.

We may even want to make a separate tree for the client interface code. We 
will need the domain building tools in dom0 to copy it into new domains, and 
how that's packaged is an unanswered question.

I'm also planning to rename the directory, since I especially hate "of" in 
lowercase as an abbreviation. I'm leaning towards "clientinterface" right 
now, but "firmware" is also a possibility. However, we could someday add Xen 
support to other firmwares like SLOF... that would allow users to run a 
bootloader to select the kernel for their domU without needing access to dom0 
(this is a topic of some discussion for Xen/x86 right now as well).

Of course, we will still want to move the client interface to use the 
flattened device tree as the Xen/firmware interface. The firmware would then 
provide the standard IEEE1275 client interface to the OS. This is on the todo 
list on the wiki.

-- 
Hollis Blanchard
IBM Linux Technology Center

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.