From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Xen/arm: Virtual ITS command queue handling Date: Fri, 15 May 2015 14:24:05 +0100 Message-ID: <1431696245.8943.127.camel@citrix.com> References: <1431442942.8263.175.camel@citrix.com> <555239ED.2090400@citrix.com> <1431523416.8263.273.camel@citrix.com> <55535F30.7040903@citrix.com> <1431687548.8943.74.camel@citrix.com> <1431689412.8943.91.camel@citrix.com> <5555E0A7.7050002@citrix.com> <1431694418.8943.115.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vijay Kilari Cc: Stefano Stabellini , Prasun Kapoor , manish.jaggi@caviumnetworks.com, Julien Grall , "xen-devel@lists.xen.org" , Julien Grall , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Fri, 2015-05-15 at 18:44 +0530, Vijay Kilari wrote: > On Fri, May 15, 2015 at 6:23 PM, Ian Campbell wrote: > > On Fri, 2015-05-15 at 18:17 +0530, Vijay Kilari wrote: > >> On Fri, May 15, 2015 at 5:33 PM, Julien Grall 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? > Also to handle second bullet, where a batch of commands might be > sent on multple pITS. In that case batch of ITS commands is split > across pITS and we have > to wait for all the pITS to complete. Managing this would be difficult. > For this I propose, batch can be created/split such that each batch > contains commands related to one pITS. But it leads to small batch of commands. That's not a bad idea, commonly I would expect commands for one device to come in a short batch anyway. So long as the thing does cope if not I think this might work. > > >> > Aside ignoring the second bullet it's not possible to drop like that a > >> > SYNC/INVALL command sent be the guest. How can you decide when a SYNC is > >> > required or not? Why dropping "optional" SYNC would be fine? The spec > >> > only says "This command specifies that all actions for the specified > >> > re-distributor must be completed"... > >> > >> If Xen is sending SYNC/INVALL commands to pITS based on the commands > >> Xen is sending on pITS, there is no harm in ignoring guest commands. > >> > >> SYNC/INVALL are always depends on previous ITS commands. > >> IMO, Alone these commands does not have any significance. > >> > >> > > >> > Linux is not a good example for respecting the spec. Developers may > >> > decide to put SYNC differently in new necessary place and we won't be > >> > able to handle it correctly in Xen (see the vGICv3 re-dist example...). > >> > > >> > If we go on one vITS per multiple pITS we would have to send the command > >> > SYNC/INVALL to every pITS. > >> > > >> > Regards, > >> > > >> > -- > >> > Julien Grall > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel