[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |