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

Re: [Xen-devel] Still porting problem



2014-10-06 15:12 GMT+01:00 Frediano Ziglio <freddy77@xxxxxxxxx>:
> Hi,
>   still trying to port Xen on a new ARM platform.
>
> Last week I suspected interrupts was not arriving to the guest
> machine. Today I got the confirm... however I don't understand why
> exactly does not work.
>
> Xen should map the GICV into the guest GICC so writing to GICH_LR
> should raise an interrupt into the guest. However I don't know ARM
> that much and I don't understand how this magic should work. I mean
> Xen is executing and try to inject an IRQ into a guest after getting a
> VTIMER interrupt (I put some trace on Linux kernel and I see it
> setting up the VTIMER and enabling the interrupt throw the GICD
> virtual interface correctly). Xen allocate an LR register and set
> it... and nothing happen. Well, I don't know even if this is the
> expected behaviour. Linux calls set_handle_irq with gic_handle_irq so
> I'm expecting gic_handle_irq to be called after Xen write into LR but
> is not.
>
> How actually this should work? Is directly the hardware (in this case
> I suspect the GIC) that send an interrupt to switch execution from L2
> to L1 into the vector table? Or should be Xen in some way that
> manually do the switch?
>
> Should I suspect an hardware bug?
>

Got some great progress, not that far from an hardware bug... GICH
registers are a bit different from standard GICv2.

Frediano

> I'm attaching the FDT tables, passed to Xen (hip04-d02.dtf directly in
> xen file) and the one that pass Xen to dom0 (ccc.fdt).
>

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


 


Rackspace

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