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

Re: [Xen-devel] Problem porting Xen on ARM

On Thu, 2 Oct 2014, Frediano Ziglio wrote:
> Hi,
>   I'm trying to support this platform
> https://wiki.linaro.org/Boards/D01 on Xen. The platform has a slightly
> different GIC v2 to support 16 cores (basically ITARGET on GICD was
> extended to accomodate 16 bits instead of 8). Did the change and added
> support for platform (setting up additional CPUs). Timers are working
> fine (I get interrupts).
> Now dom0 starts but it stops after a while. I have serial access so I
> was able to dump registers and I got this:
> http://pastebin.com/rK5Amze8. As you can note last 8 CPUs are idle
> while the other 8 are assigned to dom0 (Xen has 16 CPUs while dom0 has
> only 8). I noted that CPU 0 is the only one that has no host state. Is
> that normal? Should not have state, at least when timer interrupts are
> executed. I suspect for some reason does not setup properly the first
> CPU.
> I still don't know that much ARM architecture so surely I'm doing
> something wrong. It's not clear to me which devices should seen by
> dom0 and which devices should not be seen, actually

You could read:


Xen only drives:

- one uart
- the gic
- the smmu
- arch_timers

> - physical generic timer is hidden by Xen and replaced with a virtual
> one (provided with a virtual hardware function);

Xen emulates a physical timer and provides also a virtual timer.

> - should I hide additional timers? Actually if I do Linux hangs trying
> to calibrate delays (quite odd, why it does not use generic timer to
> do the same?);

You should pass them on to dom0

> - physical GIC is half virtualized (GICD is fully virtualized while
> for GICC a virtual physical function is used);


> - physical memory is virtualized by Xen (which present only part of it);


> - physical serial is hidden (as used for the console);

Only one uart is taken over by Xen and used for its own console

> - I had to hide physical control interface (used to setup additional
> CPU) as Linux was attempting to physically initialize the CPUs again;

What physical control interface? Can you provide a link?

> - Xen add a psci device to replace the physical control interface;

Right, that is used to boot secondary virtual cpus

> - others are passed (with FDT) trasparently to dom0.
> Should I post the FDT before and after Xen handle it?

Yes, please

Xen-devel mailing list



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