Following directions in doc/src/BUILD.md, everything went fine until: cargo start-qemu

then I get:

BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM00005 " from PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0xFFFF,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM00001 " from PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM00001 " from PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)

right as Limine's interface comes up in qemu . . . Limine then boots automatically and the following:

is all that flashes quickly before Qemu crashes.

the same happens with: cargo start-qemu --profile release

I'm on a fresh install of Mint Linux 20 Cinnamon (which is based on Ubuntu 20.04). It's not a virtual machine install; it's on a Gateway ZX6900 machine.

I don't see how to put a "Bug" Label on this Issue. I'm guessing I don't have permissions to do it? Maybe someone who does can label this "Bug".

Implements an intended part of the thread_sync API: If an empty slice of operations is passed to thread_sync along with a timeout Duration, thread_sync will just sleep the specified amount of time, allowing for easy and efficient sub-second sleeping.

Addresses #98

Alternatively, we could pass a sleep operation to a local stack word that will never awaken, and thus use timeout for the same effect. This would make the in-kernel implementation slightly simpler, but would make sleeping more expensive and involve more coordination.

It would be nice if we could leverage rust-standard behavior for writing things like #[test] in the kernel and in user-level OS services (for testing low-level Twizzler libraries like twizzler_abi) and integrate this with the build system so we can easily run the test framework as part of a github actions run.

This (large, sorry) set of changes represents a first set of changes for implementing the driver abstractions. While this in in-progress (and thus this change set is incomplete), I wanted to start the process for merging some of this in. This set adds a significant amount of framework that will hopefully make future PRs smaller and easier to work with.

Primary changes are in the twizzler-driver crate, the twizzler-abi crate, and in the kernel (interrupt handling and in-kernel PCIe support).

This set of patches is part 1 in a series that intends to stabilize the twizzler-abi crate for an initial version. We'll have to do this in steps because some parts of this crate are awaiting RFCs for their design, so can't be included yet. I'd like to get to the point where we're only adding ASAP, followed by a v1 once we can say that the core RFCs have been implemented.

This set cleans up the syscall file by splitting it up and adds a few syscalls for object stating, deletion, etc. It also adds missing documentation for much of the crate.

The kernel's thread-local storage allocator only works in some limited cases. See the userspace version (src/lib/twizzler-abi/src/rt1.rs) for a better algorithm. We should use that for the kernel too.

This PR updates the rust toolchain to 2022-10-01 nightly, up from version 1.56. This involves a rebase for all the Twizzler patches in rust, llvm, backtrace, libc, etc. We also update some of the dependencies in xtask and the kernel, and update the boot protocol (see below).

Note that pulling in these changes will require a submodule update AND a re-execution of the cargo bootstrap command.

The update to the boot protocol (from stivale2 to limine) is because the debug kernel is now too large (from all the debug symbols) to load by the older version of our bootloader, but the newer version doesn't support stivale2 anymore. And the upgrade to the limine protocol was fairly easy.

Please don't merge this PR until I verify that the new futex-based mutexes are working properly (these are located in the rust repo, because they are in stdlib).

Implements -k/--kernel flag for xtask build and check. This PR does not implement this flag for start-qemu. It should be possible to, for example, only compile the kernel and then start qemu, or only run kernel tests. However, this would require changing the initrd/disk image process.

This PR contains a multitude of minor changes to device driver APIs that make them easier to use, and fixes bugs in the interrupt mechanism.

First, the PR contains a bunch of testing code as I am dog-fooding an NVMe driver. That is all in nvme_test.rs, and does not need reviewing.

The biggest changes are in interrupt handling, wherein the PCIe code is actually in-place to program MSI-x tables and allocate interrupts from the kernel. A lower level change is that now external device interrupts get enqueued for a higher soft interrupt handler to actually wake threads (since this could involve mem allocation and mutex locking).

Otherwise, there are a number of minor API changes / additions to make working with the device APIs smoother.

I plan to, in a separate PR, continue to dogfood and cleanup some of the code. I just wanted to get some of this in now since it includes API changes.

Finishes the DMA pool aspect of the DMA RFC ( https://github.com/twizzler-operating-system/twizzler/issues/84 ). Adds in automatic compaction of the freelist when a region is freed.

This PR implements support for pinning pages of object memory for use in DMA, and implements functions in the twizzler-driver::dma module for managing DMA objects and DMA memory regions, including managing syncing and pins. It does not include implementation of the DMA pool functions, which will be done in a future PR.

This in an incremental PR for RFC#0006 ( #84 ).

In the early days of development the type Nanoseconds was used to represent the semantic time unit.

https://github.com/twizzler-operating-system/twizzler/blob/66b8f2729afcbba0b4ab9b1e6fff2c902e42964b/src/kernel/src/clock.rs#L16-L20

However, PR #78 introduced new time types to be used in kernel and by users. To make things coherent we should make any notion of time used in the kernel match up with those APIs. This requires a number of things:

• [ ] replace internal usage of Nanoseconds with type exposed by twizzler-abi
• [ ] make TimeSpan feature parity with Duration to be used as a drop in replacement
• [ ] type safe conversion between time types (Nanoseconds) and Ticks

Tracking issue for RFC 0005 -- Driver Model PR, Rendered

Steps

• [ ] Implement RFC
  • [ ] Device Event Stream
  • [ ] Request manager
• [ ] Adjust documentation
  • [ ] API docs
  • [ ] Twizzler developer guide

Unresolved Questions

• [ ] 1. One unresolved question is in the ergonomics of building a driver that uses all these types that reference each other. I plan to dogfood this interface by way of an NVMe driver.
• [x] 2. Details of DMA.

Implementation History

• https://github.com/twizzler-operating-system/twizzler/pull/81

Tracking issue for RFC 0004 -- low level device model. Links: PR, Rendered

Steps

• [ ] Implement RFC
  • [ ] Kernel-side device tree management
  • [ ] Kernel-side device tree access
  • [ ] Userspace data structures and device abstraction
• [ ] Complete documentation
  • [ ] API docs
  • [ ] Twizzler developer guide

Unresolved Questions

• [ ] 1. Is the interrupt mechanism sufficient (for now) to allow effective programming of devices?
• [ ] 2. What is the correct security model to apply here? Probably a set a approved programs can access the device tree and that's it.
• [ ] 3. Some PCIe devices should have their memory mapped as write-combining (framebuffers, for example), but PCIe doesn't encode this information in the BARs. We need a way for userspace to perhaps remap a BAR as WC.

Implementation History

• https://github.com/twizzler-operating-system/twizzler/pull/81

Create a set of sample programs that show the uses of Twizzler. These should also be integrated into the test suite so that we know that Twizzler is working even after changes.

Expand on our BUILD docs to explain to people how to get started using Twizzler as an OS in their own projects, as well as how to work on Twizzler itself.