[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.