You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed in #503, it is believed that xtdc are not in fact required. sscratchc can be used to store whatever capability you need on entry to the kernel, and from there you can have any additional state you need stored. FreeBSD already uses it to store a pointer to per-CPU data when running in userspace, and so in CheriBSD we can extend it to also store DDC for hybrid kernels (implementation at CTSRD-CHERI/cheribsd@2178d40) rather than needing a separate register.
Does anyone have a reason why they believe xtdc should remain in the specification?
The text was updated successfully, but these errors were encountered:
As discussed in #503, it is believed that xtdc are not in fact required. sscratchc can be used to store whatever capability you need on entry to the kernel, and from there you can have any additional state you need stored. FreeBSD already uses it to store a pointer to per-CPU data when running in userspace, and so in CheriBSD we can extend it to also store DDC for hybrid kernels (implementation at CTSRD-CHERI/cheribsd@2178d40) rather than needing a separate register.
Does anyone have a reason why they believe xtdc should remain in the specification?
The text was updated successfully, but these errors were encountered: