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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 15 Jan 2014, Nathan Whitehorn wrote:
> 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?

SPI: Shared Peripheral Interrupt
PPI: Private Peripheral Interrupt

PPIs are per processor interrupts.


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

The PPI and the memory region advertized under the Xen hypervisor node
on device tree are used to setup the basic infrastructure (grant table,
event channels) needed by Xen paravirtualized devices.

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