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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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?

If it involves waiting for the h/w then I think we probably don't want
to be blocking things for that length of time.

If it just involves the translation and queuing into the physical its
driver then it might be tolerable, but I'd like to see an argument as to
why that is the case.

Ian.

> 
> This is wrong. The command processing is an asynchronous process and can
> be long.
> 
> A VCPU may want to do other things (like handling interrupt) while the
> ITS is processing.
> 
> With your implementation you rule out this possibility.
> 
> > Also ITS commands are sent while setting up device/irq and while
> > releasing device/irq.
> > So there should not be any overhead when device is under use.
> 
> Ok.
> 
> >> Finally, in environment with multiple guests using ITS, the ITS command 
> >> send
> >> to the physical ITS may be interleaved (i.e DOM1 cmd, DOM2 cmd, DOM1 cmd
> >> ...). Is there any possible side-effect?
> > 
> > Each command is independent.  Generally SYNC/INV is followed after some
> > commands. But it should not be a problem if they are interleaved.
> 
> What happen if the guest decide to not send the SYNC/INV? What is the
> state of the ITS in this case? Would it be possible to receive a wrong LPIs?
> 
> Regards,
> 



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