Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@ZhanYF
Copy link

@ZhanYF ZhanYF commented Jun 26, 2025

Use loop and respect the limit parameter for seL4_TCB_WriteRegisters and seL4_TCB_ReadRegisters.

This addresses issue #1085 and currently only affects arm64.

Diff for the generated sel4_client.h:
https://gist.github.com/ZhanYF/3b36cb35591352bd1d094b1724ef7993

I tested this with libvmm on Odroidc4 and qemu and it worked OK, please let me know if you have any feedback.

Use loop and respect the limit parameter for seL4_TCB_WriteRegisters
and seL4_TCB_ReadRegisters.

This addresses issue seL4#1085 and currently only affects arm64.

Signed-off-by: [email protected] <[email protected]>
@ZhanYF ZhanYF force-pushed the yifei/optimization-1085 branch from 668154b to 9b8db0b Compare June 26, 2025 08:28
Copy link
Contributor

@Indanz Indanz left a comment

Choose a reason for hiding this comment

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

Thanks for spending time on this.

Although your solution solves the initial issue for Aarch64, the problem applies to all architectures. I would be fine with writing the few first registers unnecessarily to get rid of the magic 2 and 4 numbers.

It only solves it for the syscall wrappers, it doesn't make things any easier for user space, which has the same problem of being forced to set each individual register one by one. Basically, the user space API is horrible, but we also don't want to break it.

Normally the solution for that would be to use an anonymous union. That would mean changing seL4_UserContext, wrap all existing fields in an unnamed union and add an union containing a regs[] array of the right size. Doing this is standard C11 and seL4_UserContext is only used by user space, so I think it should be fine.

@lsf37
Copy link
Member

lsf37 commented Jun 26, 2025

Normally the solution for that would be to use an anonymous union. That would mean changing seL4_UserContext, wrap all existing fields in an unnamed union and add an union containing a regs[] array of the right size. Doing this is standard C11 and seL4_UserContext is only used by user space, so I think it should be fine.

Sorry, libsel4 is in scope for verification in the future and that's exactly the kind of thing that would break it. So we should not do that.

We could add a second unrelated API function, though, that uses an array instead and just happens to call the same kernel invocation.

@Indanz
Copy link
Contributor

Indanz commented Jun 27, 2025

Surely that's a long-term project that will take years. By then we can remove the union and only keep the array. Or we just define two structures and add a wrapper that calls the verified one with a cast (and I'd suggest making the array version verified, as that is closer to the actual kernel code).

@lsf37
Copy link
Member

lsf37 commented Jun 29, 2025

Surely that's a long-term project that will take years.

That doesn't mean we should let the code diverge from the verification subset. We've just spent extra work last year to bring it into the subset again. There is a solution without unions, I see no reason to not use that.

@ZhanYF
Copy link
Author

ZhanYF commented Nov 5, 2025

Thanks for your feedback! Would it be an acceptable solution if I port my changeset to other archs and get rid of the magic 2 and 4 numbers? I think the userspace API is still an issue but that can be addressed at a later stage.

@Indanz
Copy link
Contributor

Indanz commented Nov 5, 2025

Thanks for your feedback! Would it be an acceptable solution if I port my changeset to other archs and get rid of the magic 2 and 4 numbers? I think the userspace API is still an issue but that can be addressed at a later stage.

I think so, yes.

@Indanz
Copy link
Contributor

Indanz commented Dec 17, 2025

When #1551 gets merged it may be easier to add a new, duplicate function that uses arrays.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants