Define who assigns and matches the token for requests

[wmamills]

From Bertrand:
I think we have something unclear here that we should define: who is generating the token and handling the correlation ?

All models are possible:

1. transport generating the token and doing correlation
2. bus generating token and doing correlation
3. transport generating token and bus doing correlation
4. bus generating token and transport doing correlation

In my view solutions 3 and 4 do not make sense as the one doing correlation must be in charge of generating the token.

I see some arguments to consider:

a bus that only handles one message a time does not need the token -> in favor of 2
a bus doing the correlation would want to generate itself the token, same for transport -> against 3 and 4
having the token and correlation handled at transport level would allow to reuse some code and simplify the bus work -> in favor of 1
in case of 1, the bus would still have to handle its own correlation for bus messages -> in favor of 2
OS blocking semantics for drivers might be easier to handle in the transport to prevent busses to potentially block where they should not -> in favor of 1
I am in favor of 1, even if the bus would have to handle correlation for its own messages because of the OS blocking semantics arguments but definitely something open for discussion.

[wmamills]

Today AMP does the thread resumption in the bus. Resuming the right thread means matching the token. So this is number 2 above. This is required from the nature of the interface between transport and bus: one call with pointer to tx data and (optional) pointer to rx buffer.

If we change to number 1 we would need to change the interface between transport and bus.

Of course this choice can be made per implementation. Linux could do it one way and BSD or RTOS a different way. So I would prefer to keep it out of the virtio spec.

[bertrand-marquis]

I do agree that 2 is the right solution for now.
If this is the case then we might simplify a bit the spec by saying that the "uid" field is for bus internal purpose and can be used to correlate requests to answers. This is to say that the field is for the bus and the transport should not try to use it for any purpose.