[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 underlyingdefinitionswhere we wait for the standards to mature before we implement. In somecases, wherematurity hasn't happened, or where the bindings are overly Linuxcentric (which intheory they aren't supposed to be, but sometimes wind up that way).where we've notimplemented 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |