Skip to content

Merge master into next #521

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

Merged
merged 49 commits into from
Dec 1, 2024
Merged

Conversation

Freax13
Copy link
Member

@Freax13 Freax13 commented Nov 30, 2024

This PR syncs next with the changes on master. The only merge conflict was the changelog.

Freax13 and others added 30 commits May 24, 2024 12:16
…frame

constify PhysFrame functions
Ensure that Page actually implements Hash
Starting with the latest nightly, this results in an error:

error: avoid using labels containing only the digits `0` and `1` in inline assembly
  --> src/instructions/segmentation.rs:81:18
   |
81 |                 "1:",
   |                  ^ use a different label that doesn't start with `0` or `1`
   |
   = note: an LLVM bug makes these labels ambiguous with a binary literal number
   = note: `#[deny(binary_asm_labels)]` on by default
don't use label starting with `1`
Add size and len for PageRange, PhysFrameRange, PageRangeInclusive and PhysFrameRangeInclusive
fix testing
This feature will be stable as of Rust 1.80 and so enabling it explicitly
throws a warning.
…8-15

remove #![feature(asm_const)]
Make `GDT::append` and `GDT::push` `const` by default. The `const_fn` feature is now a no-op.
…fs-feature

Remove stabilized `const_mut_refs` feature
Fix clippy warnings
rustc is phasing out allowing the "x86-interrupt" ABI on non-x86
targets. Using "x86-interrupt" on a non-x86 target currently causes a
warning, but this will become a hard error in a future version.

Previously, if `abi_x86_interrupt` was enabled (it's enabled by default
), we used it in a pointer type for the declaration of the `HandlerFunc`-
family of types and used a private empty tuple if `abi_x86_interrupt`
wasn't enabled. This patch changes the cfg gate to only use the
"x86-interrupt" abi on x86 targets. This is technically a breaking
change, but I'd like to argue that we shouldn't treat it as such:
The danger with treating this as a breaking change is that we can't
release this fix as a patch update and so once rustc eventually treats
this as an error, we might not yet have released the next breaking
version leaving our users with not published fix.
My hope is that there is no one using `HandlerFunc` on a non-x86 target.
Even today, declaring a function (not just a function pointer) with the
"x86-interrupt" abi on a non-x86 target causes an error, so it's
unlikely that this will affect real code. It's technically possible to
create a `HandlerFunc` on a non-x86 target by using transmute, but,
again my hope is that no one is actually doing that. I'd also like to
point out that the only use of a `HandlerFunc` on a non-x86 target
would be to call set_handler_fn and any such calls could simply be
replaced by calls to set_handler_addr.
Both Intel's and AMD's manuals describe the INVPCID descriptor as a
128-bit value with the linear address stored in the upper half and the
PCID stored in the lower half. x86 uses little-endian byte ordering and
so the lower half (pcid) should be stored before the upper half
(address). Previously, our `InvpcidDescriptor` type stored the halves
in the opposite order with the address before the pcid. This patch
fixes the order, so that the pcid is stored before the address. This
new order is also the order used by Linux and OpenBSD:
https://github.com/torvalds/linux/blob/3e5e6c9900c3d71895e8bdeacfb579462e98eba1/arch/x86/include/asm/invpcid.h#L8
https://github.com/openbsd/src/blob/4e368faebf86e9a349446b5839c333bc17bd3f9a/sys/arch/amd64/include/cpufunc.h#L173
It's beyond me how this wasn't noticed earlier. The previous incorrect
layout could lead to TLB entries not being flushed and #GP faults.
fix field order for INVPCID descriptor
It turns out that dtolnay/rust-toolchain sets the installed toolchain
as the global default, but rustup prioritizes our rust-toolchain.toml.
Instead, set an environment variable. RUSTUP_TOOLCHAIN has a higher
priority than rust-toolchain.toml [^1].

[^1]: https://rust-lang.github.io/rustup/overrides.html#overrides
fix CI job for building on MSRV
gate HandlerFunc behind target_arch = "x86{_64}"
Rename the enum and add a deprecated type alias for the old name.
fix typo in "InvPicdCommand"
mrjbom and others added 19 commits November 16, 2024 12:46
…ctor

TryFrom implementation for ExceptionVector
Co-authored-by: Tom Dohrmann <[email protected]>
Typo fix in TaskStateSegment comment
Minor clarification DescriptorTablePointer::limit comment
A recent nightly changed the signature of Step::steps_between to match
the signature of Iterator::size_hint. This patch changes our
implementations to match the new signature.
Without the as_slice call, the value passed to from_ptr was &[i32; 5]
which is *not* a slice.
Previously, we scaled count as a usize, not a u64. This is bad because
stepping forward by 0x10_0000 is perfectly fine, yet we were always
rejecting this because 0x10_0000 * 0x1000 doesn't fit in usize on
32-bit platforms. Similarly, we would fail to return a step count above
or equal to 0x10_0000 because the call to
<VirtAddr as Step>::steps_between would fail.
Never scale usize values, instead, always scale u64 values. To make
this easier to work with, this patch adds variants of the Step
functions to VirtAddr that take and return u64 instead of usize.
This patch also adds some regression tests.
…eakage

fix signature of Step::steps_between implementations
release 0.15.2
@Freax13 Freax13 merged commit 8ca2ab9 into rust-osdev:next Dec 1, 2024
11 of 13 checks passed
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.

None yet

4 participants