From: Ian Campbell <ian.campbell@citrix.com>
To: Vijay Kilari <vijay.kilari@gmail.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Prasun Kapoor <Prasun.Kapoor@caviumnetworks.com>,
manish.jaggi@caviumnetworks.com,
Julien Grall <julien.grall@linaro.org>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Julien Grall <julien.grall@citrix.com>,
Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: Xen/arm: Virtual ITS command queue handling
Date: Fri, 15 May 2015 14:24:05 +0100 [thread overview]
Message-ID: <1431696245.8943.127.camel@citrix.com> (raw)
In-Reply-To: <CALicx6uGQb=6YkNk4sH67tvmU1U0md1yP2NxWvPFv7OQVwChQw@mail.gmail.com>
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@citrix.com> 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@citrix.com> 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
next prev parent reply other threads:[~2015-05-15 13:24 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-05 12:14 Xen/arm: Virtual ITS command queue handling Vijay Kilari
2015-05-05 13:51 ` Stefano Stabellini
2015-05-05 13:54 ` Julien Grall
2015-05-05 15:56 ` Vijay Kilari
2015-05-05 14:09 ` Julien Grall
2015-05-05 16:09 ` Vijay Kilari
2015-05-05 16:27 ` Julien Grall
2015-05-12 15:02 ` Ian Campbell
2015-05-12 17:35 ` Julien Grall
2015-05-13 13:23 ` Ian Campbell
2015-05-13 14:26 ` Julien Grall
2015-05-15 10:59 ` Ian Campbell
2015-05-15 11:26 ` Vijay Kilari
2015-05-15 11:30 ` Ian Campbell
2015-05-15 12:03 ` Julien Grall
2015-05-15 12:47 ` Vijay Kilari
2015-05-15 12:52 ` Julien Grall
2015-05-15 12:53 ` Ian Campbell
2015-05-15 13:14 ` Vijay Kilari
2015-05-15 13:24 ` Ian Campbell [this message]
2015-05-15 13:44 ` Julien Grall
2015-05-15 14:04 ` Vijay Kilari
2015-05-15 15:05 ` Julien Grall
2015-05-15 15:38 ` Ian Campbell
2015-05-15 17:31 ` Julien Grall
2015-05-16 4:03 ` Vijay Kilari
2015-05-16 8:49 ` Julien Grall
2015-05-19 11:38 ` Vijay Kilari
2015-05-19 11:48 ` Ian Campbell
2015-05-19 11:55 ` Ian Campbell
2015-05-19 12:10 ` Vijay Kilari
2015-05-19 12:19 ` Ian Campbell
2015-05-19 12:48 ` Vijay Kilari
2015-05-19 13:12 ` Ian Campbell
2015-05-19 14:05 ` Julien Grall
2015-05-19 14:48 ` Ian Campbell
2015-05-19 15:44 ` Julien Grall
2015-05-15 14:05 ` Ian Campbell
2015-05-15 12:19 ` Julien Grall
2015-05-15 12:58 ` Ian Campbell
2015-05-15 13:24 ` Julien Grall
2015-05-19 12:14 ` Ian Campbell
2015-05-19 13:27 ` Julien Grall
2015-05-19 13:36 ` Ian Campbell
2015-05-19 13:46 ` Julien Grall
2015-05-19 13:54 ` Ian Campbell
2015-05-19 14:04 ` Vijay Kilari
2015-05-19 14:18 ` Ian Campbell
2015-05-21 12:37 ` Manish Jaggi
2015-05-26 13:04 ` Ian Campbell
2015-06-01 22:57 ` Manish Jaggi
2015-06-02 8:29 ` Ian Campbell
2015-05-19 14:06 ` Julien Grall
2015-05-13 16:27 ` Vijay Kilari
2015-05-15 11:28 ` Ian Campbell
2015-05-15 12:38 ` Vijay Kilari
2015-05-15 13:06 ` Ian Campbell
2015-05-15 13:17 ` Julien Grall
2015-05-15 11:45 ` Xen on ARM vITS Handling Draft B (Was Re: Xen/arm: Virtual ITS command queue handling) Ian Campbell
2015-05-15 14:55 ` Julien Grall
2015-05-19 12:10 ` Ian Campbell
2015-05-19 13:37 ` Julien Grall
2015-05-19 13:51 ` Ian Campbell
2015-05-22 12:16 ` Vijay Kilari
2015-05-22 12:49 ` Julien Grall
2015-05-22 13:58 ` Vijay Kilari
2015-05-22 14:35 ` Julien Grall
2015-05-22 14:54 ` Vijay Kilari
2015-05-24 10:35 ` Julien Grall
2015-05-25 9:06 ` Vijay Kilari
2015-05-25 9:32 ` Julien Grall
2015-05-25 10:40 ` Vijay Kilari
2015-05-25 12:44 ` Julien Grall
2015-05-25 13:38 ` Vijay Kilari
2015-05-25 17:11 ` Julien Grall
2015-05-27 11:22 ` Ian Campbell
2015-05-27 11:22 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1431696245.8943.127.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Prasun.Kapoor@caviumnetworks.com \
--cc=julien.grall@citrix.com \
--cc=julien.grall@linaro.org \
--cc=manish.jaggi@caviumnetworks.com \
--cc=stefano.stabellini@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=vijay.kilari@gmail.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).