Re: [XenPPC] XenPPC IEEE1275 binding?

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

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