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

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

On Mon, 13 Feb 2017, Bhupinder Thakur wrote:
> Hi Stefano,
> On 9 February 2017 at 05:40, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
> wrote:
> > On Wed, 8 Feb 2017, Bhupinder Thakur wrote:
> >> Hi Julien,
> >>
> >> On 3 February 2017 at 19:38, Julien Grall <julien.grall@xxxxxxx> wrote:
> >> > So if I understand correctly, you don't receive anymore output. Correct?
> >> > Have you tried to see whether the pl011 driver is receiving interrupt or
> >> > even Linux calling it.
> >>
> >> The pl011 driver is not receiving the interrupts (I put a
> >> HYPERVISOR_console_io() call inside the interrupt handler and I do not
> >> see the print on the xen console) . When the console is in this state,
> >> if I keep typing the characters on the console then Xen keeps raising
> >> the interrupts (for each character typed) but all those interrupts are
> >> marked as inflight. So it seems that interrupt is not getting cleared
> >> in GIC. Which GIC function can I look at to further debug what is the
> >> issue?
> >>
> >> Earlier, when I used to manually write characters to /dev/ttyAMA0 then
> >> I used to receive the interrupts all fine.
> >
> > DomU doesn't get emulated PL011 interrupts from Xen? Make sure you don't
> > mark the interrupt as a real hardware interrupt by mistake
> > (GICH_V2_LR_HW). At the same time, check that the virtual PL011
> > interrupt has been added correctly to the LRs
> > (xen/arch/arm/gic-v2.c:gicv2_update_lr).
> I verified that the PL011 interrupt is getting marked pending by Xen
> but guest does not receive it. I am not sure if the local interrupt
> delivery is disabled on the guest because of which it may not be
> receiving the interrupts. Is there a way to verify that interrupts are
> indeed disabled at that point. Since the interrupt delivery works fine
> when I manually read/write characters to /dev/ttyAMA0, I think there
> is no issue from the Xen side in terms of raising an interrupt.
> One observation is that pl011_request_port () calls request_mem_region
> () for the MMIO space allocated to pl011. The function returns -EBUSY
> indicating that the memory region is already in use. But when I do cat
> /proc/iomem, I do not see any overlaps. I am using 0x22000000 as the
> start of the pl011 MMIO space. I see the same error while booting the
> dom0 kernel also.
> I have attached the guest boot logs when console=ttyAMA0. I have added
> debug prints marked with [DEBUG]. I added debug prints in amba-pl011.c
> and serial_core.c. The output from the console seems to suddenly stop
> once the pl011 port is started. I have not added getty for ttyAMA0 in
> the /etc/inittab file. I believe auto-serial-console should be able to
> attach a getty session to ttyAMA0 automatically (i did try with adding
> a getty command in the inittab file but that did not solve the issue).
> Towards the end of the log, we can see that every time a character is
> typed, Xen raises an interrupt and the characters keep getting
> collected in the IN RING buffer (in_prod keeps incrementing). Later
> interrupts remain in inflight as the earlier interrupt is not cleared.

Let me get this straight: who is printing all those messages we see on
the guest console (xl console guest) up until "Freeing unused kernel
memory"?  Is it the early pl011 driver? Or is it the Xen PV console

Are you using a DEBUG build of Xen? Only DEBUG builds allow DomUs to
issue HYPERVISOR_console_io hypercalls. You might want to check that
do_console_io in Xen is letting DomU calls through.

Otherwise pl011_int might actually be called but the printk might not
show up on the Xen console.

The interrupt is enabled from Xen point of view, otherwise it would not
be added to the LR. However Linux might still refuse to call the
interrupt handler for some reason. You might want to add a printk in the
Linux generic interrupt handler, probably
kernel/irq/chip.c:handle_fasteoi_irq in your case.

Xen-devel mailing list



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