[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |