[Question] HSM START_PENDING when hart_start request never completes

[Shibo Zhu]

Hi OpenSBI maintainers,

I have a question about the failure semantics of
sbi_hsm_hart_start() when a start backend reports success but the
target hart never makes progress.

The relevant generic HSM flow appears to be:

STOPPED
   |
   | sbi_hsm_hart_start()
   v
START_PENDING
   |
   | issue wake/start request
   v
backend returns success

For the generic path, OpenSBI may use an IPI to wake the target hart.

After the wake/start backend reports success, sbi_hsm_hart_start()
returns SBI_SUCCESS while the target remains in START_PENDING.

Normally, the target hart later enters the OpenSBI warm-start path and
eventually calls sbi_hsm_hart_start_finish(), which performs:

START_PENDING -> STARTED

and releases the start ticket.

The case I am interested in is when the backend reports success, but
the target hart never responds and therefore never reaches
sbi_hsm_hart_start_finish().

In that case, the state appears to remain:

state        = START_PENDING
start_ticket = held

indefinitely.

A later hart_start() request for the same hart cannot proceed because
the previous start request still owns the start ticket.

What makes this case interesting to me is the distinction between a
wake/start backend reporting success and knowing that the target hart
will actually execute.

For example, an IPI implementation may successfully perform its
send-side operation, but that does not necessarily establish that the
target hart received the interrupt, started executing, or will
eventually complete the HSM startup sequence.

Once the backend has returned success, I do not see a generic path
that can later determine that the outstanding start request has failed
and safely transition:

START_PENDING -> STOPPED

The target hart itself normally owns the successful completion path,
while the requesting hart has already returned from
sbi_hsm_hart_start().

I would like to understand the intended contract here.

When the generic IPI path or a platform HSM hart_start() backend
returns success, is it expected to guarantee that the target hart
will eventually reach the HSM startup completion path?
If the backend reports success but the target hart never responds,
is an indefinitely START_PENDING hart considered an expected
consequence of a platform/backend failure, or is there intended to
be a recovery mechanism at the generic HSM layer?
Is it intentional that generic HSM only handles synchronous backend
failures, while failures discovered after a successful backend
return are outside the generic HSM failure model?
More generally, what is the intended ownership of an outstanding
START_PENDING request after sbi_hsm_hart_start() has returned
SBI_SUCCESS but before the target reaches
sbi_hsm_hart_start_finish()?

I am mainly trying to understand the intended HSM state-machine and
backend contract here. I am not proposing a code change at this point.

Thanks,
Shibo Zhu