[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest
On Wed, 15 Feb 2017, Bhupinder Thakur wrote: > On 15 February 2017 at 13:45, Bhupinder Thakur > <bhupinder.thakur@xxxxxxxxxx> wrote: > > Hi Stefano, > > > > On 14 February 2017 at 03:14, Stefano Stabellini <sstabellini@xxxxxxxxxx> > > wrote: > >> 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 > >> driver? > >> > >> 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. > > > > The pl011 console is working now. I did not fix any thing specific > > except I cleaned up the debug code which I had added. I am not sure if > > some of my debug code was causing the issue. > > > > After cleaning up the debug code and building the code afresh, I > > started receiving the interrupts and input/output on the console is > > working fine. Now I am able to execute commands on the console. > > > I believe since I was using printk in the pl011 console driver code > for debugging, that might be causing some infinite loop. Once I > replaced all printks with HYPERVISOR_console_io(), it started working. > Later I compiled out the debug code, and it was working fine. Yep, I tripped over that problem myself at least once or twice :-) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |