Re: [Xen-devel] [Draft F] Xen on ARM vITS Handling

[Julien Grall <julien.grall@xxxxxxxxxx>]

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.

> (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.
> > 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.

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

Regards,

--
Julien Grall

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