Skip to content

LiteBox kernel platform and machine runner#491

Draft
sangho2 wants to merge 21 commits intomainfrom
sanghle/hypervisor/bootloader
Draft

LiteBox kernel platform and machine runner#491
sangho2 wants to merge 21 commits intomainfrom
sanghle/hypervisor/bootloader

Conversation

@sangho2
Copy link
Contributor

@sangho2 sangho2 commented Nov 13, 2025

This PR covers an initial effort to have a minimal LiteBox kernel platform and a test runner to use the kernel platform on top of a virtual machine (i.e., QEMU, KVM) to run a hello-world OP-TEE TA.

@sangho2 sangho2 changed the title PoC: LiteBox hypervisor platform and runner PoC: LiteBox machine platform and runner Nov 17, 2025
@sangho2 sangho2 changed the title PoC: LiteBox machine platform and runner LiteBox machine platform and runner Nov 17, 2025
@sangho2 sangho2 changed the title LiteBox machine platform and runner WIP: LiteBox machine platform and runner Nov 17, 2025
@sangho2 sangho2 force-pushed the sanghle/hypervisor/bootloader branch from 7d79944 to 65341b9 Compare November 19, 2025 00:00
@sangho2 sangho2 changed the title WIP: LiteBox machine platform and runner WIP: LiteBox kernel platform and machine runner Nov 19, 2025
@sangho2 sangho2 force-pushed the sanghle/hypervisor/bootloader branch from a2ff438 to b77ec38 Compare November 19, 2025 18:37
@sangho2 sangho2 changed the title WIP: LiteBox kernel platform and machine runner LiteBox kernel platform and machine runner Nov 19, 2025
@sangho2 sangho2 marked this pull request as ready for review November 19, 2025 19:17
@sangho2 sangho2 marked this pull request as draft November 19, 2025 19:22
@sangho2 sangho2 force-pushed the sanghle/hypervisor/bootloader branch from 34085b4 to fb312be Compare November 19, 2025 19:40
@sangho2 sangho2 marked this pull request as ready for review November 19, 2025 19:57
@wdcui wdcui requested review from CvvT and jstarks November 20, 2025 01:07
@wdcui
Copy link
Member

wdcui commented Nov 20, 2025

@jstarks @CvvT I think we should merge this minimal kernel platform into LiteBox. Can you please help take a look at this PR? Thanks!

@wdcui
Copy link
Member

wdcui commented Nov 20, 2025

@sangho2 would it make sense to move the changes to the lvbs platform to a separate PR?

@CvvT
Copy link
Contributor

CvvT commented Nov 20, 2025

@jstarks @CvvT I think we should merge this minimal kernel platform into LiteBox. Can you please help take a look at this PR? Thanks!

Why we need to merge it into LiteBox? I thought it should be a separate crate for common kernel functionality like litebox_common_linux.

@wdcui
Copy link
Member

wdcui commented Nov 20, 2025

@jstarks @CvvT I think we should merge this minimal kernel platform into LiteBox. Can you please help take a look at this PR? Thanks!

Why we need to merge it into LiteBox? I thought it should be a separate crate for common kernel functionality like litebox_common_linux.

Sorry. I meant to merge it into the LiteBox repo. :-)

@sangho2
Copy link
Contributor Author

sangho2 commented Nov 20, 2025

@sangho2 would it make sense to move the changes to the lvbs platform to a separate PR?

The are simple bug fixes but I agree that a separate PR makes more sense.

Copy link
Member

@wdcui wdcui left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for creating this minimal kernel platform, Sangho. I left some minor comments. Please wait for comments from John and Weiteng.

@sangho2 sangho2 force-pushed the sanghle/hypervisor/bootloader branch 2 times, most recently from a3977b4 to 62f5896 Compare November 20, 2025 05:51
@sangho2 sangho2 force-pushed the sanghle/hypervisor/bootloader branch from 927a573 to eb4cb38 Compare November 20, 2025 23:01
@github-actions
Copy link

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

Copy link
Contributor

@CvvT CvvT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot of the code seem to be duplicated from other platforms, which make this PR difficult to review. I can quickly draft a PR to move some common code into a separate crate. Will try to clean up the code later.

#[unsafe(naked)]
unsafe extern "C" fn syscall_entry_wrapper() {
naked_asm!(
"swapgs",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may also need to swap stack?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, definitely.

syscall is pretty tricky to get right in the general case (e.g., what happens if you get an NMI before you swap GS? Does your NMI handler look at GS?). A simpler approach, which we'll take in Coconut initially, is to not enable the syscall instruction, so that a syscall causes a #UD exception. Then, in the #UD handler, you can read two bytes at RIP, and if it's a syscall instruction, you can emulate it. This is slower than syscall but is easier to reason about.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now we are using the kernel stack. Disabling syscall sounds interesting.

"pop r11",
"pop rbp",
"swapgs",
"sysretq",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to the syscall side of things, I suggest we start with iret here. I like the way Linux handles this--they treat sysret as an optimization for switching to user mode when rcx == rip and r11 == rflags. It doesn't matter if they entered from an interrupt or exception or syscall, just that the context matches what would happen if they entered via a syscall.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now we are using iretq instead of sysretq.

/// Represent a user space pointer to a read-only object
#[repr(C)]
#[derive(Clone)]
pub struct UserConstPtr<T> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use the existing common_providers implementation right away instead of cloning another copy of this?

@sangho2 sangho2 marked this pull request as draft December 2, 2025 22:35
@sangho2
Copy link
Contributor Author

sangho2 commented Dec 2, 2025

Draft for now. I'll enhance it while transferring portions of it to the LVBS platform.

@jstarks jstarks mentioned this pull request Dec 16, 2025
2 tasks
@sangho2 sangho2 added the must-not-merge:prototype An experimental/proof-of-concept PR that must not be merged. label Dec 17, 2025
@sangho2
Copy link
Contributor Author

sangho2 commented Dec 18, 2025

Overall Progress/Plan:

  • I've updated this PR to catch up some recent changes related to run_thread.
  • I'll port these changes to the LVBS platform.
  • Once the LVBS platform is ready (OP-TEE and syscall supports), I'll work on this PR again to clean it up (and hopefully support multi cores and linux shim).

@sangho2 sangho2 added must-not-merge:undergoing-restructuring Known deeper set of changes are happening on this PR before it is mergeable again and removed must-not-merge:prototype An experimental/proof-of-concept PR that must not be merged. labels Dec 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

must-not-merge:undergoing-restructuring Known deeper set of changes are happening on this PR before it is mergeable again

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants