Re: [Xen-devel] Xen on ARMv8

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-12-11 at 16:16 +0000, Stefano Stabellini wrote:
> On Wed, 11 Dec 2013, Vijay Kilari wrote:
> > On Tue, Dec 10, 2013 at 6:29 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> > wrote:
> > > On Tue, 2013-12-10 at 18:18 +0530, Vijay Kilari wrote:
> > >> On Tue, Dec 10, 2013 at 5:59 PM, Vijay Kilari <vijay.kilari@xxxxxxxxx> 
> > >> wrote:
> > >> > On Mon, Dec 9, 2013 at 7:34 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> > >> > wrote:
> > >> >> On Mon, 2013-12-09 at 19:22 +0530, Vijay Kilari wrote:
> > >> >>> On Fri, Dec 6, 2013 at 8:55 PM, Ian Campbell 
> > >> >>> <Ian.Campbell@xxxxxxxxxx> wrote:
> > >> >>> I don't have any work around as of now. I just reverted changes made
> > >> >>> to pl011 driver in staging branch on top of stable 4.3. I see couple 
> > >> >>> of
> > >> >>> patches that has changed pl011 registers initialization.
> > >> >>>
> > >> >>> I will check once I get the my setup is up & running.
> > >> >>
> > >> >> OK, thanks.
> > >> >>
> > >> >>>
> > >> >>> >> (XEN) Using PSCI for SMP bringup
> > >> >>> [..]
> > >> >>> >> (XEN) Panic on CPU 0:
> > >> >>> >> (XEN) Unable to copy the DTB to dom0 memory (rc = 
> > >> >>> >> 18446744073709551602)
> > >> >>> >> (XEN) ****************************************
> > >> >>> >
> > >> >>> > It looks like you are trying to load an ELF format kernel, which
> > >> >>> > probably doesn't work for Linux. Try passing it the
> > >> >>> > arch/arm64/boot/Image and it should work.
> > >> >>> >
> > >> >>> > (ELF is useful for *BSD I think, which is why we don't just nuke 
> > >> >>> > this
> > >> >>> > support right now)
> > >> >>> >
> > >> >>> Yes, I have set my Image to vmlinux (stripped) for 4.3 stable as it  
> > >> >>> was failing
> > >> >>> to load plain arch/arm64/boot/Image
> > >> >>> I forget to revert back this change with staging branch. Now I could
> > >> >>> boot Xen hypervisor.
> > >> >>
> > >> >> Excellent!
> > >> >>
> > >> >>> Thanks for this help.
> > >> >>>
> > >> >>> But my console on dom0 is not showing any logs.
> > >> >>> However ARMv8 simulator shows that dom0 is booted and
> > >> >>> cpu has entered idle loop.
> > >> >>
> > >> >> Do you have console=hvc0 on your dom0 command line and CONFIG_HVC_XEN 
> > >> >> in
> > >> >> your kernel build?
> > >> >>
> > >> >
> > >> > Changing console=hvc0 works.
> > >> >
> > >> > Kernel boot still fails. I have my rootfs of IDE(ATA) on AHCI. Because 
> > >> > there is
> > >> > no link up interrupt from IDE and hence it fails to boot and mount 
> > >> > rootfs.
> > >> > Where as the same kernel boots fine without Xen
> > >> >
> > >> > From HW traces, I see that GIC does not raise IRQ.
> > >> >
> > >> > I am using kernel 3.10.14+. Can you please let me know Dom0 kernel
> > >> > configuration.
> > >
> > >> Missed to mention. On top of 3.10.14 I added following patches for arm64
> > >>
> > >> 1e33368 arm/xen: define xen_remap as ioremap_cached
> > >> 71750f7 arm64/xen: introduce asm/xen header files on arm64
> > >> a554a92 xen/arm and xen/arm64: implement HYPERVISOR_tmem_op
> > >> b80ef86 arm64/xen: introduce CONFIG_XEN and hypercall.S on ARM64
> > >> 7605d0c xen/arm: disable cpuidle and cpufreq when linux is running as 
> > >> dom0
> > >
> > > 3.10.x plus those might be ok.
> > >
> > > The big thing which comes to mind that you will be missing here is the
> > > swiotlb stuff which Stefano did, which went into v3.13-rc1 (with some
> > > subsequent fixups). Stefano probably remembers better than I what went
> > > into the kernel since 3.10.
> > >
> > > I'm mostly tracking mainline myself and you might find it easier to move
> > > up to something more recent rather than backport the swiotlb stuff.
> > >
> > > You might also want to investigate Stefano's "interrupt handling fixes"
> > > to the hypervisor side -- IIRC they are related to failures similar to
> > > the one you are seeing.
> > >
> > 
> > I have taken v3 version of Stefano's interrupt patches for Xen and
> > 3.13.rc2 kernel
> > and the issue is same as 3.10.14+
> > 
> > The issue seems to be with timer. The ATA driver calls for hardware reset
> > and calls msleep(1) in kernel thread context before it checks for link 
> > status.
> > The msleep(1) never schedules this kernel thread back and hence Dom0
> > boot is not complete.
> 
> Are you getting any interrupts in dom0?
> Arch_timer interrupts and interrupts for the ATA controller at all?

The other thing to check is that platform->dom0_evtchn_ppi (default
==irq 31, ppi 15) doesn't conflict with a real interrupt number.

Ian.


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