-
Notifications
You must be signed in to change notification settings - Fork 130
Remove hypervisor_handler thread #533
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
eb85e5f
to
4abdd49
Compare
c4d0a52
to
210e506
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some comments/questions , not quite finished reviewing , I will finish it in the morning
34a5772
to
baf9912
Compare
2374355
to
b1f7d4c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work! 💯
I tested it locally. 😺
2220073
to
0dc8686
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM , nice work @ludfjig
7a21f4c
to
a931dd2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good. Thanks for the fix on the SIGRTMIN
offset stuff!
To finish off this PR, I think we just have to update some docs. Doing a quick search for "hypervisor handler" in the project shows references in shared_mem.rs
, guest.rs
, how-to-debug-a-hyperlight-guest.md
, and the copilot-instructions.md
.
Also, I think we should update the signal-handlers-development-notes.md
doc to be appropriate to what we have rn.
Signed-off-by: Ludvig Liljenberg <[email protected]>
Signed-off-by: Ludvig Liljenberg <[email protected]>
Signed-off-by: Ludvig Liljenberg <[email protected]>
Signed-off-by: Ludvig Liljenberg <[email protected]>
… sandbox Signed-off-by: Ludvig Liljenberg <[email protected]>
…, but a new function call could be scheduled, before the interruptor-thread has time to observe the fact that the vcpu was interrupted Signed-off-by: Ludvig Liljenberg <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!!
kill()
api. Currently, one can only cancel guest function calls, not the first vm initialization, but this should be fine as long as you trust your guest binary. You can only interrupt a guest while it's in a blocking call tovcpufd.run()
. Host function calls can still not be interrupted (Make it possible to kill guest execution when running a host function. #192)These changes should improve performance and throughput. It should also avoid the incredible performance drop off we observed under load when the hypervisor handler thread required joining, after cancelling guest execution.
Added API changes:
Removed API changed:
closes #471
Note: On KVM, moving the vcpufd (sandbox) to a new thread will incur a performance overhead the first time the vcpu in ran on the new thread, as per kvm kernel docs