-
Notifications
You must be signed in to change notification settings - Fork 143
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
+549
−121
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Much like 4aaa21c, but for PhysAddr.
Loading status checks…
Loading status checks…
…frame constify PhysFrame functions
Loading status checks…
Loading status checks…
Ensure that Page actually implements Hash
Loading status checks…
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
Loading status checks…
don't use label starting with `1`
Loading status checks…
Loading status checks…
Add size and len for PageRange, PhysFrameRange, PageRangeInclusive and PhysFrameRangeInclusive
Loading status checks…
Loading status checks…
fix testing
Loading status checks…
This feature will be stable as of Rust 1.80 and so enabling it explicitly throws a warning.
Loading status checks…
…8-15 remove #![feature(asm_const)]
Loading status checks…
Make `GDT::append` and `GDT::push` `const` by default. The `const_fn` feature is now a no-op.
Loading status checks…
Loading status checks…
…fs-feature Remove stabilized `const_mut_refs` feature
Loading status checks…
Fix clippy warnings
Loading status checks…
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.
Loading status checks…
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.
Loading status checks…
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
Loading status checks…
Loading status checks…
fix CI job for building on MSRV
Loading status checks…
gate HandlerFunc behind target_arch = "x86{_64}"
Loading status checks…
Rename the enum and add a deprecated type alias for the old name.
Loading status checks…
fix typo in "InvPicdCommand"
Loading status checks…
Loading status checks…
…ctor TryFrom implementation for ExceptionVector
Co-authored-by: Tom Dohrmann <[email protected]>
Co-authored-by: Tom Dohrmann <[email protected]>
Loading status checks…
Co-authored-by: Tom Dohrmann <[email protected]>
Loading status checks…
Typo fix in TaskStateSegment comment
Loading status checks…
Loading status checks…
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.
Loading status checks…
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.
Loading status checks…
…eakage fix signature of Step::steps_between implementations
Loading status checks…
Loading status checks…
release 0.15.2
Loading status checks…
phil-opp
approved these changes
Nov 30, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR syncs next with the changes on master. The only merge conflict was the changelog.