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

[Brandon Perez <a0225893@xxxxxx>]

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.
>
> Ian.
    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.
Brandon

Attachment: xenctx_guest.dump
Description: Text document

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