Return code when api_spci_msg_recv() succeeds

[Hong-Seok Kim]

According to the SPCI specification, when SPCI_MSG_WAIT and SPCI_MSG_POLL return successfully, they are supposed to return SPCI_SUCCESS. On the other hand, in the current implementation, it appears they return SPCI_MSG_SEND_32 instead.

static struct spci_value spci_msg_recv_return(const struct vm *receiver)

{

    return (struct spci_value){

        .func = SPCI_MSG_SEND_32,

        .arg1 = (receiver->mailbox.recv_sender << 16) | receiver->id,

        .arg3 = receiver->mailbox.recv_size,

        .arg4 = receiver->mailbox.recv_attributes};

}

Could you confirm if this is correct?

[Andrew Walbran]

Maybe you're looking at an old version of the spec? In the latest beta I have it says for SPCI_MSG_POLL:

"• Successful completion of this function is indicated through the invocation of the SPCI_MSG_SEND interface (see Section 11.1)"

And for SPCI_MSG_WAIT:

"• Successful completion of this function is indicated through the invocation of the following functions by the callee. Each function ID encodes enough information for the caller to retrieve the message.

 – SPCI_INTERRUPT at any SPCI instance

 – Any framework message function at the secure physical SPCI instance

 – Message transmission functions at the secure physical SPCI instance

 – SPCI_MSG_SEND at any virtual SPCI instance if the partition supports receipt of indirect messages

 – SPCI_MSG_SEND_DIRECT_REQ at any virtual SPCI instance if the partition supports receipt of direct messages"

[Hong-Seok Kim]

I am looking at the following version:

2019/Nov/13 Beta 0 • Replaced some occurrences of ARM with Arm

In Section 9.8 SPCI_MSG_POLL in this version,

Poll if a message is available in the caller’s RX buffer. Execution is returned to the caller if no message is available
– Must not be invoked when the caller is processing a direct request
• Valid SPCI instances and conduits are listed in Table 81
• Syntax of this function is described in Table 78
• Returns SPCI_SUCCESS without any further parameters upon successful completion
• Encoding of error code in the SPCI_ERROR function is described in Table 79
• This is an optional interface

[Andrew Walbran]

On Wed, 20 Nov 2019 at 14:08, Hong-Seok Kim <hong...@google.com> wrote:

I am looking at the following version:

2019/Nov/13 Beta 0 • Replaced some occurrences of ARM with Arm

In Section 9.8 SPCI_MSG_POLL in this version,

Poll if a message is available in the caller’s RX buffer. Execution is returned to the caller if no message is available
– Must not be invoked when the caller is processing a direct request
• Valid SPCI instances and conduits are listed in Table 81
• Syntax of this function is described in Table 78
• Returns SPCI_SUCCESS without any further parameters upon successful completion
• Encoding of error code in the SPCI_ERROR function is described in Table 79
• This is an optional interface

Weird, that is fairly recent but seems to be missing some fixes from October. I'm meeting Arm tomorrow so I'll ask them what's happening with the versioning.

[Hong-Seok Kim]

Ok - I was wrong about SPCI_MSG_WAIT. Yes, the function code in the return value should indicate how triggered the VM to be unblocked. So, when the VM gets unblocked because it received a message, the correct function code should be SPIC_MSG_SEND.

For SPCI_MSG_POLL, it makes sense to return SPIC_SUCCESS. However, if we want it to be consistent with SPCI_MSG_WAIT, SPIC_MSG_SEND makes sense, too.

[Andrew Walbran]

On Wed, 20 Nov 2019 at 14:21, Hong-Seok Kim <hong...@google.com> wrote:

Ok - I was wrong about SPCI_MSG_WAIT. Yes, the function code in the return value should indicate how triggered the VM to be unblocked. So, when the VM gets unblocked because it received a message, the correct function code should be SPIC_MSG_SEND.

For SPCI_MSG_POLL, it makes sense to return SPIC_SUCCESS. However, if we want it to be consistent with SPCI_MSG_WAIT, SPIC_MSG_SEND makes sense, too.

Not just that, the caller of SPCI_MSG_POLL needs to know who the message is from, how long it is, and so on, which is provided in the SPCI_MSG_SEND parameters not by SPCI_SUCCESS.

[Hong-Seok Kim]

Ah - so each function code is associated with a certain message format?

--
You received this message because you are subscribed to the Google Groups "Hafnium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hafnium-discu...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/hafnium-discuss/CA%2B_y_2F_souujn1FEcjR7Lv8EaoPUhcz74y%3D_yVbUJScTLt4nQ%40mail.gmail.com.

[Andrew Walbran]

On Wed, 20 Nov 2019 at 14:41, Hong-Seok Kim <hong...@google.com> wrote:

Ah - so each function code is associated with a certain message format?

Yes, each function code specifies how the registers x2–x8 are used (or not) for parameters.

[Hong-Seok Kim]

Ok, thanks for the clarification.