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

[Julien Grall <julien.grall@xxxxxxx>]

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.
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?
> It also helps
> toward solving the INVALL potential DOS issue, because it significantly
> reduces the computation needed when an INVALL is issued by the guest.
>
> On the other end, this approach has the potential of consuming much more
> memory to map all the possible pLPIs that a device could use up to the
> theoretical max. Of course that is not good either. But fortunately for
> PCI devices we know how many events a device can generate. Also we
> should be able to get that info on device tree for other devices. So I
> suggest Xen only maps as many pLPIs as events the device can generate,
> when the device is assigned to the guest. This way there would be no
> wasted memory.
>
> Does it make sense? Do you think it could work?
Aside the point I raised above, I think the approach looks sensible.

Regards,

[1] https://xenbits.xen.org/people/ianc/vits/draftG.html#device-assignment

--
Julien Grall

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