On Aug 9, 2006, at 5:42 AM, Segher Boessenkool wrote:
Ahh the beast awakens :)
I remember seeing some mention of it, but I don't think we currently
have an IEEE1275 binding describing the contents of the /xen node.
As you're currently both the only producer and the only consumer of
this node, you don't need a real binding yet. But, the standard
properties you have should be correct; and you should make your
specific properties as sane as possible as soon as possible.
We intend to include these in the OpenPAPR :-P
start-info is going away, which means we'll need to add more
properties
to replace it... something like this:
xen {
name = "xen";
version = "Xen-3.0-unstable";
Call this property "xen-version" instead?
Isn't that redundant?
Should we have a "compatible" that domain can compare against?
Yes, but you also should have a "device_type".
The is not a device node, I'd rather not add that here, but console
should have one, see below.
reg = <0 @DOMAIN_ID@ 0 0>;
This could certainly be "domain-id" and be one cell.
If it's a 32-bit number always -- if not, make it two cells.
I used "reg" because I mistakenly thought is was a mandatory
property and we needed a "unit-id" which makes no sense as you
point out below.
If you only ever have one "xen" node, you don't need the "reg".
reg, begone!
It is 2x2 cells because:
/#address-cells: 2
/#size-cells: 2
and they dictate the size of the unit-address.
Only #address-cells actually; but "reg" contains a size as well.
domain-name = "@DOMAIN_NAME@";
shared = <@SHARED_INFO@>;
This, console and store, and all addresses should be expressed in
bytes and are domain-physical not MFNs so we should label them
correctly. They also need to match /#address-cells and should
prolly have a size.
privileged;
init-domain;
I have no idea what these last three props describe; please
explain? (And perhaps make the names more specific).
They are domain flags, telling the it has priveldge to all of the
machine (trusted), and that it is dom0, respectively.
console {
name = "console";
we should add a device_type here:
device_type = "serial";
compatible = "xencons";
Will Xen ever support multiple consoles? I don't think so.
interrupts = <@CONSOLE_EVTCHN@ 0>;
FYI, the second zero here denotes a sense code of 0 indicating
positive edge triggered interrupt
Well no. A node's "interrupts" property's semantics depends
on the interrupt-controller it points to. You don't point to
anything yet.
Are those interrupts "virtual" interrupts? In that case, you
want to have a "xen-interrupt-controller" node; or you could
even just put an "interrupt-controller" in the main "xen" node.
Thats a good point, a "/xen/interrupt-controller" is a good idea, but
we should make it an empty property like the PAPR /vdevice, and then
each "device" can use the encoding we have above.
All virtual irqs will have the same sense/value, so you can do
without that second cell in the interrupt specifiers completely.
These may be the only 2 that ever see a device trww since everything
else is "hot plugged" using Xen hcalls.
We are not sure if the we'll be dyamically adding hotplug virtual
devices to the devtree at runtime, we just ain't there yet. It think
I'd like to keep the encoding, just in case.
frameno = <@CONSOLE_MFN@>;
Perhaps this should be a "unit address" and be a reg property,
that actually makes sense.
Can't comment; what is this?
};
store {
name = "store";
interrupts = <@STORE_EVTCHN@ 0>;
frameno = <@STORE_MFN@>;
this could be a "reg"/"unit address" as well.
You need #address-cells and #size-cells in the parent node for
that, btw.
Do we need them? don't they get "ancestored in"? if not then yes we
should add them.
-JX
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
Home