On 01/15/14 10:24, Julien Grall wrote:
On 01/15/2014 01:26 AM, Warner Losh wrote:
On Jan 14, 2014, at 2:01 PM, Julien Grall wrote:
This new support brings 2 open questions (for both Xen and FreeBSD community).
When a new guest is created, the toolstack will generated a device tree which
- The amount of memory
- The description of the platform (gic, timer, hypervisor node)
- PSCI node for SMP bringup
Until now, Xen on ARM supported only Linux-based OS. When the support of
device tree was added in Xen for guest, we chose to use Linux device tree
bindings (gic, timer,...). It seems that FreeBSD choose a different way to
implement device tree:
- strictly respect ePAR (for interrupt-parent property)
- gic bindings different (only 1 interrupt cell)
I would like to come with a common device tree specification (bindings, ...)
across every operating system. I know the Linux community is working on having
a device tree bindings out of the kernel tree. Does FreeBSD community plan to
work with Linux community for this purpose?
We generally try to follow the common definitions for the FDT stuff.
There are a few cases where we either lack the feature set of Linux, or
where the Linux folks are moving quickly and changing the underlying
where we wait for the standards to mature before we implement. In some
maturity hasn't happened, or where the bindings are overly Linux
centric (which in
theory they aren't supposed to be, but sometimes wind up that way).
where we've not
As I understand main bindings (gic, timer) are set in stone and won't
change. Ian Campbell has a repository with all the ARM bindings here:
To compare the difference between the DT provided by Xen, and the one
correctly parsed by FreeBSD
- Xen: http://xenbits.xen.org/people/julieng/xenvm-4.2.dts
- FreeBSD: http://xenbits.xen.org/people/julieng/xenvm-bsd.dts
>From Xen side:
- Every device should move under a simple-bus. I think it's harmless
for Linux side.
- How about hypervisor node? IHMO this node should also live under the
>From FreeBSD side:
- GIC and Timer bindings needs to be handled correctly (see below the
problem for the GIC)
- Less stricter about interrupt-parent property. Eg, look at the
grant-parent if there is no property interrupt-parent
- If the hypervisor doesn't live under simple-bus, the interrupt/memory
retrieving should be moved from simple-bus to nexus?
Before the revision r260282 (I have added Nathan on cc), I was able to
use the Linux GIC bindings (see
without any issue.
It seems the fdt bus, now consider the number of interrupt cells is
Thanks for the CC. Could you explain what you mean by "grant-parent"
etc? "interrupt-parent" is a fundamental part of the way PAPR (and
ePAPR) work, so I'm very very hesitant to start guessing. I think things
have broken for you because some (a lot, actually) of OF code does not
expect #interrupt-cells to be more than 2. Some APIs might need
updating, which I'll try to take care of. Could you tell me what the
difference between SPI and PPI is, by the way?
On the subject of simple-bus, they usually aren't necessary. For
example, all hypervisor devices on IBM hardware live under /vdevice,
which is attached to the device tree root. They don't use MMIO, so
simple-bus doesn't really make sense. How does Xen communicate with the
OS in these devices?
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"