Repository navigation
Conversation
Freax13
left a comment
There was a problem hiding this comment.
Thank you for your contribution!
Another important problem is adding tests. QEMU has FRED support through KVM, which is not helpful if the host computer does not have FRED. Bochs could be used however.
I tested this PR on some hardware that supports FRED and it seems to be working.
|
Thank you for your reviews, I pushed the changes requested on the last review. |
|
Whoops, I pushed the wrong changes to your branch and GitHub automatically closed the PR. And now that the PR is closed, I can no longer push changes to your branch to fix that mistake. Could you reset your branch to Freax13@5419a84 and then re-open the PR? I did not mean to close this PR, I just wanted to push one small fix before merging it. |
Hello, and thank you for developing and maintaining this crate.
I recently had a need of using Flexible Return and Event Delivery (FRED), but the crate did not implement it. So here is a pull request, in case it might be considered.
Basically, FRED is a very recent CPU architecture change, and the first commercial CPUs came out around the beginning of this year I believe. Many (nearly all) major operating systems support it. It replaces IDT-based delivery and IRET with defined entry points, a consistent event frame, separate stack levels for nested events, and the ERETS and ERETU return instructions.
For the initial PR, I did not want to do any design choices myself, and I would like opinions from the maintainers on how to shape the API (if it looks good, or if some things need changes).
What is implemented in this PR:
These are all very simple wrappers around the Intel FRED specification (rev 9.0). It does not provide a software entry point, handler dispatch, or wrappers for ERETS and ERETU.
Another important problem is adding tests. QEMU has FRED support through KVM, which is not helpful if the host computer does not have FRED. Bochs could be used however.