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. 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. 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. > 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. It involves waiting the h/w. > 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. 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. Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
