fix warnings

Much like 4aaa21c, but for PhysAddr.

…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"

…ctor

TryFrom implementation for ExceptionVector

Co-authored-by: Tom Dohrmann <[email protected]>

Co-authored-by: Tom Dohrmann <[email protected]>

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.