Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 25 Nov 2016, Julien Grall wrote:
> Hi,
> 
> On 18/11/16 18:39, Stefano Stabellini wrote:
> > On Fri, 11 Nov 2016, Stefano Stabellini wrote:
> > > On Fri, 11 Nov 2016, Julien Grall wrote:
> > > > On 10/11/16 20:42, Stefano Stabellini wrote:
> > > > That's why in the approach we had on the previous series was "host ITS
> > > > command
> > > > should be limited when emulating guest ITS command". From my recall, in
> > > > that
> > > > series the host and guest LPIs was fully separated (enabling a guest
> > > > LPIs was
> > > > not enabling host LPIs).
> > > 
> > > I am interested in reading what Ian suggested to do when the physical
> > > ITS queue is full, but I cannot find anything specific about it in the
> > > doc.
> > > 
> > > Do you have a suggestion for this?
> > > 
> > > The only things that come to mind right now are:
> > > 
> > > 1) check if the ITS queue is full and busy loop until it is not (spin_lock
> > > style)
> > > 2) check if the ITS queue is full and sleep until it is not (mutex style)
> > 
> > Another, probably better idea, is to map all pLPIs of a device when the
> > device is assigned to a guest (including Dom0). This is what was written
> > in Ian's design doc. The advantage of this approach is that Xen doesn't
> > need to take any actions on the physical ITS command queue when the
> > guest issues virtual ITS commands, therefore completely solving this
> > problem at the root. (Although I am not sure about enable/disable
> > commands: could we avoid issuing enable/disable on pLPIs?)
> 
> In the previous design document (see [1]), the pLPIs are enabled when the
> device is assigned to the guest. This means that it is not necessary to send
> command there. This is also means we may receive a pLPI before the associated
> vLPI has been configured.
> 
> That said, given that LPIs are edge-triggered, there is no deactivate state
> (see 4.1 in ARM IHI 0069C). So as soon as the priority drop is done, the same
> LPIs could potentially be raised again. This could generate a storm.

Thank you for raising this important point. You are correct.


> The priority drop is necessary if we don't want to block the reception of
> interrupt for the current physical CPU.
> 
> What I am more concerned about is this problem can also happen in normal
> running (i.e the pLPI is bound to an vLPI and the vLPI is enabled). For
> edge-triggered interrupt, there is no way to prevent them to fire again. Maybe
> it is time to introduce rate-limit interrupt for ARM. Any opinions?

Yes. It could be as simple as disabling the pLPI when Xen receives a
second pLPI before the guest EOIs the first corresponding vLPI, which
shouldn't happen in normal circumstances.

We need a simple per-LPI inflight counter, incremented when a pLPI is
received, decremented when the corresponding vLPI is EOIed (the LR is
cleared).

When the counter > 1, we disable the pLPI and request a maintenance
interrupt for the corresponding vLPI.

When we receive the maintenance interrupt and we clear the LR of the
vLPI, Xen should re-enable the pLPI.

Given that the state of the LRs is sync'ed before calling gic_interrupt,
we can be sure to know exactly in what state the vLPI is at any given
time. But for this to work correctly, it is important to configure the
pLPI to be delivered to the same pCPU running the vCPU which handles
the vLPI (as it is already the case today for SPIs).

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