Re: [Xen-devel] [RFC PATCH v2 13/22] xen/arm: its: Add virtual ITS command support

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-04-01 at 13:02 +0100, Julien Grall wrote:
> On 01/04/15 12:46, Ian Campbell wrote:
> > On Mon, 2015-03-30 at 16:47 +0100, Julien Grall wrote:
> >>> In any case ITS commands are processed in synchronously. So any VCPU that
> >>> send ITS commands is blocked.
> > 
> > What exactly is synchronous here? Is it just the "translate vits into
> > requests queued with the physical its driver" phase or does it also
> > include waiting for the physical its' response and translating that back
> > into a v response?
> 
> From the spec, the processing of command is asynchronous.

I was asking about the implementation of our emulation of it, not about
the hardware itself. I understood that the underlying h/w is
asynchronous.

>  The vCPU has
> to poll a register in order to know if the ITS has finished to execute
> the command.
> 
> A vCPU may decide to execute other things while the ITS is processing
> commands.
> 
> The implementation suggested by Vijay, both the vCPU and CPU is blocked
> while the ITS command are processing.

Can we just enqueue with the hardware and use the guest vcpu polling
loop to trigger us to check for completion? What would happen if a guest
never polled, I suppose we would have to catch it some other way?

> Futhermore, if another vCPU is trying to access the vITS it will be
> blocked too (and therefore the CPU). With this solution we may take down
> Xen.

Yes, we can't have that I'm afraid.

> The translation/queuing can be very long if the queue is big (the
> maximum size of the queue is 2^32). It would at least require some
> preemption in Xen in order to avoid blocking the CPU/vCPU for a long time.

Yes, limiting the number of requests in flight at any one time seems
like a good idea anyway, we can always dribble things in as other ones
complete anyway.

Ian.


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