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

Re: [Xen-devel] [RFC] Add support for Xen ARM guest on FreeBSD



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
will contains:
        - 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
definitions
where we wait for the standards to mature before we implement. In some
cases, where
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
implemented things.
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:
http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;
a=tree;f=Bindings/arm

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
simple-bus.

>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
http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=Bindings/arm/gic.txt)
without any issue.

It seems the fdt bus, now consider the number of interrupt cells is
always 1.



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?
-Nathan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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