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

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi,

On 09/07/2015 15:55, Brandon Perez wrote:
> On 07/09/2015 03:34 AM, Julien Grall wrote:
>  > 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.
Do you receive other interrupts in the guest?

>     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)?
The timer IRQs for DOM0 and the guest may be different. DOM0 will use 
the same as the hardware (i.e the one in your log), while guests have a 
their interrupt defined in the guest layout (see 
xen/include/public/arch-arm.h).
>     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.
I think you are mixing two different things here:
	- gic_handle_irq is the Linux interrupt handler for GICv2 where every 
IRQ is coming (PPIs, SPIs...)
        - vtimer_interrupt and timer_interrupt are Xen handlers which 
will take of the timer IRQs of the hardware.
When the hardware fire a virtual interrupt it will be:
        1) Received by Xen via gic_interrupt
        2) do_IRQ will dispatch the IRQ
	3) virtual_interrupt will be called has it has been registered as 
callback for the virtual timer
	4) The interrupt will be injected to the guest using the guest virtual 
interrupt number. I.e the LRs will be setup
        5) The guest will receive the interrupt
        6) gic_handle_irq will dispatch the interrupt

>     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);
This call is only used for IRQ owned by the domain.

In the case of the timer IRQs, they are owned by Xen and therefore not 
directly injected to the guest.
>     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?
The file vtimer.c contains anything related to the guest timer: 
emulation of the physical timer and context/restore of both virtual and 
physical timer.
The injection of the timer interrupts will be done in different place:
	- virtual: this is done in vtimer_interrupt (xen/arch/arm/timer.c) when 
the domain is running. If the domain is not running, we create a timer 
and may inject an interrupt if the timer has expired (see 
virt_timer_expired in xen/arch/arm/vtimer.c).
	- physical: the timer is completely emulated. The injection of the 
interrupt is done in phys_timer_expired (xen/arch/arm/vtimer.c).
You can add printk in those place to check whether the interrupt is 
injected to the guest or not. It may give you an insight of whether the 
timer has been correctly setup by the guest or not.
Note that you may want to only print when it's not domain 0 to avoid log 
pollution.
>      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.
May I ask you to provide
        - the .config used to build the kernel
	- a link to the git repo containing the branch (I wasn't able to find 
it on your first mail)
You also said you had local changes in both Linux and Xen. Can you tell 
us what kind of changes?	
Regards,

--
Julien Grall

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