Date: Sat, 18 Jan 2014 20:08:12 -0700 From: Warner Losh <imp@bsdimp.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD Message-ID: <8C16C019-B9AF-417B-9B02-C016A202AAC7@bsdimp.com> In-Reply-To: <52DB3FFD.2070503@freebsd.org> References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> <52D73C4E.2080306@freebsd.org> <52D87B15.5090208@linaro.org> <52D89DC9.7050303@freebsd.org> <52DB1138.6010804@linaro.org> <3AE8EDE6-D931-4F93-9BF7-ABFB297B5B96@bsdimp.com> <52DB3FFD.2070503@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 18, 2014, at 8:01 PM, Nathan Whitehorn wrote:
> On 01/18/14 20:44, Warner Losh wrote:
>> On Jan 18, 2014, at 4:41 PM, Julien Grall wrote:
>>=20
>>> Hello Nathan,
>>>=20
>>> On 01/17/2014 03:04 AM, Nathan Whitehorn wrote:
>>>> On 01/16/14 18:36, Julien Grall wrote:
>>>>>=20
>>>>> On 01/16/2014 01:56 AM, Nathan Whitehorn wrote:
>>>>> As I understand, only the simple bus code (see simplebus_attach) =
is
>>>>> translating the interrupts in the device on a resource.
>>>>> So if you have a node directly attached to the root node with
>>>>> interrupts and MMIO, the driver won't be able to retrieve and
>>>>> translate the interrupts via bus_alloc_resources.
>>>> Why not? nexus on ARM, MIPS, PowerPC, and sparc64 can do this.
>>> I have digged into the code to find the reason of my issue. FreeBSD =
is receiving a VM fault when the driver (xen-dt) is trying to setup the =
IRQ.
>>>=20
>>> This is because the GIC is not yet initialized but FreeBSD asks to =
unmask the IRQ (sys/arm/arm/gic.c:306).
>>>=20
>>> With this problem, all device nodes that are before the GIC in the =
device tree can't have interrupts. For instance this simple device will =
segfault on FreeBSD:
>>>=20
>>> / {
>>>=20
>>> mybus {
>>> compatible =3D "simple-bus";
>>>=20
>>> mynode {
>>> interrupt-parent =3D &gic;
>>> interrupts =3D <...>;
>>> };
>>>=20
>>> gic: gic@xxxx {
>>> interrupt-controller;
>>> }
>>> };
>>> };
>>>=20
>>> The node "mynode" will have to move after the GIC to be able to work =
correctly.
>> This stems from a difference in enumeration between FreeBSD and =
Linux. FreeBSD enumerates the devices in DTB order, while Linux does a =
partial ordering based on dependencies.
>>=20
>> Warner
>=20
> Enumerating in some other order doesn't necessarily help: since the
> interrupt and bus trees are independent, circular dependencies can
> happen. This is not a hypothetical: on most powermacs, the main
> interrupt controller is a functional unit on a PCI device -- a PCI
> device whose other units have interrupt lines that eventually connect
> back to itself. There is no way to fix that with ordering. So I think =
we
> still need to defer interrupt setup. It's not that bad -- PPC already
> does this to handle the powermac case.
I guess I've looked at simpler cases where interrupts and GPIO pins need =
to be up before anything can work on Atmel... We kinda fake it now, but =
there's some ordering issues that are solved in this way. But I've not =
finished the work on bringing Atmel into the FDT world yet. Deferred =
setup isn't always an option, but I'll keep that in mind in case I hit =
that case...
The other way to cope is to use the multi-pass enumeration stuff that =
John Baldwin put into the tree a while ago. In that case, you could =
enumerate bridges, interrupt controllers, gpio providers, etc first, and =
then do a second pass that catches the rest of the devices and the =
interrupt processing for the first pass devices. This is a variation on =
the deferred enumeration stuff you are talking about, so that might be a =
better, more general solution to these sorts of problems.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C16C019-B9AF-417B-9B02-C016A202AAC7>