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

Re: [Xen-devel] Xen/arm: Virtual ITS command queue handling



On Fri, 2015-05-15 at 16:05 +0100, Julien Grall wrote:
> On 15/05/15 15:04, Vijay Kilari wrote:
> > On Fri, May 15, 2015 at 7:14 PM, Julien Grall <julien.grall@xxxxxxxxxx> 
> > wrote:
> >> On 15/05/15 14:24, Ian Campbell wrote:
> >>> On Fri, 2015-05-15 at 18:44 +0530, Vijay Kilari wrote:
> >>>> On Fri, May 15, 2015 at 6:23 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> 
> >>>> wrote:
> >>>>> On Fri, 2015-05-15 at 18:17 +0530, Vijay Kilari wrote:
> >>>>>> On Fri, May 15, 2015 at 5:33 PM, Julien Grall 
> >>>>>> <julien.grall@xxxxxxxxxx> wrote:
> >>>>>>> On 15/05/15 12:30, Ian Campbell wrote:
> >>>>>>>>> Handling of Single vITS and multipl pITS can be made simple.
> >>>>>>>>>
> >>>>>>>>> All ITS commands except SYNC & INVALL has device id which will
> >>>>>>>>> help us to know to which pITS it should be sent.
> >>>>>>>>>
> >>>>>>>>> SYNC & INVALL can be dropped by Xen on Guest request
> >>>>>>>>>  and let Xen append where ever SYNC & INVALL is required.
> >>>>>>>>> (Ex; Linux driver adds SYNC for required commands).
> >>>>>>>>> With this assumption, all ITS commands are mapped to pITS
> >>>>>>>>> and no need of synchronization across pITS
> >>>>>>>>
> >>>>>>>> You've ignored the second bullet its three sub-bullets, I think.
> >>>>>>>
> >>>>>>    Why can't we group the batch of commands based on pITS it has
> >>>>>> to be sent?.
> >>>>>
> >>>>> Are you suggesting that each batch we send should be synchronous? (i.e.
> >>>>> end with SYNC+INT) That doesn't seem at all desirable.
> >>>>
> >>>> Not only at the end of batch, SYNC can be appended based on every
> >>>> command within the batch.
> >>>
> >>> Could be, but something to avoid I think?
> >>
> >> That would slow down the ITS processing (SYNC is waiting that the
> >> previous command has executed).
> >>
> >> Also, what about INTALL? Sending it everytime would be horrible for the
> >> performance because it flush the ITS cache.
> > 
> > INVALL is not required everytime. It can be sent only as mentioned in spec 
> > Note.
> > ex; MOVI
> > 
> > Note: this command is expected to be used by software when it changed
> > the re-configuration
> > of an LPI in memory to ensure any cached copies of the old
> > configuration are discarded.
> 
> INVALL is used when a large number of LPIs has been reconfigured. If you
> send one by MOVI is not efficient at all and will slowdown all the
> interrupts for few milliseconds. We need to use them with caution.
> 
> Usually a guest will send one for multiple MOVI command.

We should be prepared for a guest which does nothing but send INVALL
commands (i.e. trying to DoS the host).

I mentioned earlier about maybe needing to track which pITS's a SYNC
goes to (based on what SYNC have happened already and what commands the
guest has sent since).

Do we also need to track which LPIs a guest has fiddled with in order to
decide (perhaps via a threshold) whether to use INVALL vs a small number
of targeted INVALL?

Ian.


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


 


Rackspace

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