[RFC] Add support for Xen ARM guest on FreeBSD

Nathan Whitehorn nwhitehorn at freebsd.org
Thu Jan 16 01:56:42 UTC 2014


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


More information about the freebsd-arm mailing list