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

Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip

On 07/09/2015 03:34 AM, Julien Grall wrote:
> Hi Brandon,
> These rangesets list the interrupt and I/O memory assigned to the guest
> (i.e passthrough).
> In the case of the timer interrupt (physical and virtual), they are
> owned by Xen and Xen will emulated it for each guest.
>  From the logs the LRs are empty (see VCPU_LR) and no interrupts are
> currently pending.
> I would add some printk in function gic_handle_irq in Linux
> (drivers/irqchip/irq-gic.c, assuming you are using GICv2) to see which
> IRQ is coming. FYI, the virt timer PPI is 27 and phys timer 30.

I added that printk statement, and I never see any physical or virtual timer interrupts being delivered to the guest. I believe the guest is using the virtual timer, because when I do a more full register dump with trace32, I see that CNTV_CVAL is programmed to a non-zero value, but CNTP_CVAL is 0.

   I also noticed the following line during the Dom0 guest boot:

(XEN) Generic Timer IRQ: phys=35 hyp=31 virt=32 Freq: 6147 KHz

Is this expected to be different from the expected interrupt ID's for ARM core timers (these numbers are all offset by +5)?

Correct me if I'm wrong, but it seems like gic_handle_irq() is not the control path taken by the PPI timers. It looks like the functions "vtimer_interrupt()" and "timer_interrupt()" (xen/arch/arm/time.c) handle those interrupts.

Also, based on the following lines in xen/arch/arm/irq.c: 224-226, it seems like that the guests cannot be delivered PPI's from the function "do_IRQ()":

    /* the irq cannot be a PPI, we only support delivery of SPIs to
     * guests */
     vgic_vcpu_inject_spi(info->d, info->virq);

Also, how do the functions in xen/arch/arm/vtimer.c fit into this picture? Would they be the ones responsible for delivering the vtimer interrupt to the guest?

> Regards,

On 07/09/2015 08:06 AM, Ian Campbell wrote:
On Wed, 2015-07-08 at 10:36 -0400, Brandon Perez wrote:
      I've attached the full log from the domain dump below. But the
interesting part of the log is:

(XEN) Rangesets belonging to domain 1:
(XEN)     Interrupts { }
(XEN)     I/O Memory { }

      Perhaps I am interpreting this incorrectly, but it would seem that
no interrupts belong to domain 1?

As Julien says these only list actual physical interrupts so it's
expected unless you are doing passthrough.

As well as what Julien suggests you could try running
"$prefix/lib/xen/bin/xenctx <domid> 0" to get full register state.

    I've attached the xenctx dump.

You could also perhaps try disabling HCR_EL2.TWI and/or TWE (trap wait
for interrupts and events respectively). Ages ago we had some bugs in
these areas, those are thought to be long gone, but it's worth checking.

    No luck with that, the guest still doesn't boot successfully.

AIUI you are running the same 3.14/android kernel in both dom0 and domU.
Do you have the option of running a newer mainline kernel on your
platform, to rule out either changes made in the Android branch or
issues in the 3.14 kernel which have been fixed since.


Yes, I'm using the 3.14 kernel for both dom0 and domU. Unfortunately, I need the 3.14 kernel, but if these problems persist, I may try to update to a newer mainline kernel.


Attachment: xenctx_guest.dump
Description: Text document

Xen-users mailing list



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