Add hvc 6 yield runtime hook

[doanbaotrung]

Cooperative yield request from the HVC 6 handler. When set, the current guest run loop exits after the handler returns and control is yielded back to the host.

---

Summary by cubic

Add a cooperative yield path for HVC 6 so the handler can request the vCPU run loop to exit and return control to the host right after it returns. Introduces a thread-local runtime hook via proc_request_hvc6_yield() that vcpu_run_loop clears before the HVC 6 handler and checks after; when set, the loop stops immediately after the handler returns.

^{Written for commit 42d897a. Summary will update on new commits. Review in cubic}

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[jserv]

Chec https://cbea.ms/git-commit/ carefully and enforce the rules accordingly.

[doanbaotrung]

Updated the mesage

[jserv]

I defer to @Max042004 for confirmation.

[Max042004]

It may happen data race.
guest_t is shared between thread. If two thread are in the HVC 6 path together, thread B can read+clear the flag that thread A set — so B exits without having requested a yield.

[doanbaotrung]

Dear @Max042004

I replaced the shared guest_t flag with a thread-local yield request.

proc_request_hvc6_yield() now sets a TLS flag on the host thread currently executing the HVC 6 handler. vcpu_run_loop() clears that TLS flag before invoking the handler and consumes it immediately after the handler returns, so concurrent HVC 6 handlers on other vCPUs cannot observe or clear this thread's request.

[Max042004]

  if (hvc6_yield_requested) {
- hvc6_yield_requested = false;             
  running = false;

you can consider this change. But it is fine to remain current commit.

LGTM

[doanbaotrung]

Noted. Please allow me to keep it to avoids a mistake if future code ever checks the flag outside this exact handler path

[jserv]

Thank @doanbaotrung for contributing!