Hi Ian,
On 02/04/2015 10:13, Ian Campbell wrote:
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.
Sorry I though you were asking about the h/w. I think the end of my mail
answered the question on our implementation.
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?
Enqueue may be long. I was thinking about suggesting to use a tasklet
for processing ITS command.
But I don't know how much we can do in Xen with them.
> What would happen if a guest
never polled, I suppose we would have to catch it some other way?
The specification (see 4.9.9 PRD03-GENC-010745 24.0) defines 2 different
way to be notify for completion:
1) Polling: Reading GITS_CREADR in a loop
2) Receiving an interrupt (see 4.9.10) by using the command MAPI.
A guest would be buggy if it doesn't implement one of this solution. And
therefore may not run on real h/w.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
