[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Draft F] Xen on ARM vITS Handling
On Fri, 2015-06-12 at 09:32 -0400, Julien Grall wrote: > > On 12/06/2015 09:16, Ian Campbell wrote: > > On Fri, 2015-06-12 at 09:09 -0400, Julien Grall wrote: > >> Hi Ian, > >> > >> On 12/06/2015 04:52, Ian Campbell wrote: > >>> On Fri, 2015-06-12 at 14:07 +0530, Vijay Kilari wrote: > >>> So pLPIs must be routed at device assignment time because in the vLPI > >>> configuration table trap there is no mapping back to a single pLPI. > >> > >> I just remembered the exact reason that made use to differ SPI enabling. > > > > I can't parse this sentence, differ how? > > deferring sorry. > > > > >> When the device is assigned, the domain VCPUs are still down (even VCPU0). > >> > >> If we receive an interrupt before the VCPU0 is unpaused, the interrupt > >> will be lost. Same if the interrupt is not yet configured (i.e before > >> the vITS setup correctly the table) with your proposal. > > > > Is this any different to booting with the ITT not setup? > > I don't understand your question. During boot the ITT is not configured and a spurious event will go undelivered to an LPI then too, even on native. > > (SPIs are a slightly different case because they don't need h/w routing) > > I think you mixed PPIs with SPIs. SPIs (shared private interrupt) > requires h/w routing. I don't think they do, GICD_ICFGR (or the GICv3 equivalent) come up in a state where the interrupt will go _somewhere_, which differs from things injected via the ITS. > >> This could happen when the device is not quiescent. We had this issue on > >> the vexpress at boot time when the network card was trying to send an > >> interrupt before DOM0 is setup. > > > > I don't fully understand the issue you are trying to describe, but do > > you want to propose a change to the spec? > > I actually don't know how to modify it. So it's an open question. For SPI too, or just for LPI? > vgic_vcpu_inject_irq doesn't queue the interrupt if a VCPU is down. I > think this is because the state of the VCPU wouldn't be correct. > > The process would be something like: > > - Creation of the domain > => All vCPUs are down > > - Device is assigned to the guest > => Enable physical LPIs > > * physical LPI is received * > => Will be ignored and not EOIed (VCPU0 is down) > => The LPI will never fired again during the guest life > > - Domain is started by the toolstack > => VCPU0 is online Is it sufficient to queue interrupts even for VCPUs which are down? How does the lack of a vITT entry when this interrupt occurred affect this? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |