-
Notifications
You must be signed in to change notification settings - Fork 134
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
GlobalDescriptorTable: option/feature to increase number of entries #333
Comments
Sure, that sounds reasonable!
In long mode the x86-64 doesn't need a GDT entry for the for configuring GS segment, you have to configure the I believe we could implement this using const generics, allowing the user specify the maximum capacity. Of course we could also do the much simpler thing and simply increase the capacity to some fixed value eg. 16. We don't have any guarantees on the layout of our GDT type, so I guess/hope that changing the capacity won't break anyone's code. |
Huh! I'm not sure why but I had become convinced that it was necessary. I've just tested and you're absolutely right. Well that reduces the urgency for me. If it's convenient, or of others ask for more options, great, but I think I'm unblocked here. Thanks for your help :) |
Ah, I'd forgotten that the TSS takes up two slots in the GDT. Would it still be possible to increase the length? |
Unfortunately, this doesn't work, I misunderstood how much Rust can infer automatically. let mut gdt: GlobalDescriptorTable = GlobalDescriptorTable::new(); However this does not work: let mut gdt = GlobalDescriptorTable::new();
We could work around this by always returning To be honest, I'm not so sure anymore if const generics are the right way to solve this: A lot of our users will probably never need anything but the default, so adding const generics would add unnecessary complexity for most. I thought we could avoid this using default values, but as I already said, this turned out to be incorrect. Simply increasing the capacity will work for now, but only until the next person requires a bigger capacity. This might still be the most pragmatic solution though. Another possible solution might be to allow creating GDTs of dynamic lengths at runtime by supplying a slice of I'm open to any other suggestions or feedback! |
That's a shame. I don't want to cause a big change unnecessarily. I would be happy to avoid 32-bit user processes and therefore only need 1 (null) + 2 (kernel code/data) + 2 (TSS) + 2 (user code/data), but my intepretation of My understanding is that If I understand correctly, that means the intent is that you have both 32-bit and 64-bit segment selectors for user code, passing the 64-bit user code selector and the 32-bit user data selector to Does that make sense? Would I just be better off using |
If you only use
That being said, I still think adding more capacity could be useful e.g. for setting up setting segments for user space programs in compatibility mode, however this is probably not as urgently needed.
No need to apologize, you provided a lot of information about your current setup and what you already figured out about what the CPU wants, this is very useful to understand the requirements and possible solutions! |
Oh, I didn't realise that! I went with
Yeah, you're absolutely right. Thanks again for all your help! |
This would be fine in my opinion. Most users would just use the default size through the |
It turns out that we don't need to have a segment selector for GS to be able to use the GSBase MSR, as discussed in rust-osdev/x86_64#333. I suspect this is because we now have a kernel data segment selector for SS, which we didn't when I first added support for CPU-local data. Removing the extra selector frees up a slot in the GDT. Signed-off-by: SlyMarbo <the.sly.marbo@googlemail.com>
It turns out that we don't need to have a segment selector for GS to be able to use the GSBase MSR, as discussed in rust-osdev/x86_64#333. I suspect this is because we now have a kernel data segment selector for SS, which we didn't when I first added support for CPU-local data. Removing the extra selector frees up a slot in the GDT. Signed-off-by: SlyMarbo <the.sly.marbo@googlemail.com>
It turns out that we don't need to have a segment selector for GS to be able to use the GSBase MSR, as discussed in rust-osdev/x86_64#333. I suspect this is because we now have a kernel data segment selector for SS, which we didn't when I first added support for CPU-local data. Removing the extra selector frees up a slot in the GDT. Signed-off-by: SlyMarbo <the.sly.marbo@googlemail.com>
It turns out that we don't need to have a segment selector for GS to be able to use the GSBase MSR, as discussed in rust-osdev/x86_64#333. I suspect this is because we now have a kernel data segment selector for SS, which we didn't when I first added support for CPU-local data. Removing the extra selector frees up a slot in the GDT. Signed-off-by: SlyMarbo <the.sly.marbo@googlemail.com>
So if we had something like this: pub struct GlobalDescriptorTable<const MAX: usize = 8> {
table: [u64; MAX],
next_free: usize,
} We could just have: impl GlobalDescriptorTable {
/// Creates an empty GDT with the default length.
pub const fn new() -> Self {
Self::empty()
}
}
impl<const MAX: usize> GlobalDescriptorTable<MAX> {
/// Creates an empty GDT.
#[inline]
pub const fn empty() -> Self {
Self {
table: [0; MAX],
next_free: 1,
}
}
} That way we keep the reasonable default of 8 for |
Sounds good to me! |
Based on #355 it seems like our current MSRV when no features are enabled is Rust 1.57. Default const generic parameters were introduced in Rust 1.59, so this change will have to be on the I'll try to get a PR out with this later today. |
Fixed by #360 |
Hi there!
Would it be possible to increase the number of entries in the GDT? If you'd prefer to keep the default at 8, perhaps there could be a feature to increase it (to 16, perhaps)? To be able to use
syscall
/sysret
, I reckon you need at least 7 entries, not including the null first entry. 2 for kernel code/data, 1 for the TSS, 2 for 32-bit user code/data and 2 for 64-bit code/data. If you also want an entry to allow CPU-local data with GS, then the current type panics. It's entirely possible I'm wrong, which would be great.Thanks for all your hard work.
The text was updated successfully, but these errors were encountered: