osdev | Fourth rewrite of LevOS , aiming for POSIX compliance | TCP library

That page on osdev.org contains code intended to be run when the CPU is in 16-bit real mode.
You can tell not only from the registers involved but also from the fact that int 10h is used.
This is a well-known BIOS interrupt service that is written in 16-bit real-mode code.

If you target UEFI, then your bootloader is actually an UEFI application, which is a PE32(+) image.
If the CPU is 64-bit capable, the firmware will switch into long mode (64-bit mode) and load your bootloader.
Otherwise, it will switch into protected mode (32-bit mode).
In any case, real mode is never used in UEFI.

You can call 16-bit code from protected/long mode with the use of a 16-bit code segment in the GDT/LDT but you cannot call real-mode code (i.e. code written to work with the real-mode segmentation) because segmentation works completely different between the modes.
Plus, in real mode the interrupts are dispatched through the IVT and not the IDT, you would need to get the original entry-point for interrupt 10h.

Luckily, UEFI has a replacement for most basic services offered by the legacy BIOS interface.
In this case, you can use the EFI_EDID_DISCOVERED_PROTOCOL and eventually apply any override from the platform firmware with the use of EFI_EDID_OVERRIDE_PROTOCOL.

The EFI_EDID_DISCOVERED_PROTOCOL is straightforward to use, it's just a (Size, Data) pair.

How can I Implement It in My OS?

The first step is to determine the pixel geometry (see https://en.wikipedia.org/wiki/Pixel_geometry ); because if you don't know that any attempt at sub-pixel rendering is likely to just make the image worse than not doing sub-pixel rendering at all. I've never been able to find a sane way to obtain this information. A "least insane" way is to get the monitor's EDID/E-EDID (Extended Display Identification Data - see https://en.wikipedia.org/wiki/Extended_Display_Identification_Data ), extract the manufacturer and product code, and then use manufacturer and product code to find the information somewhere elsewhere (from a file, from a database, ..). Sadly this means that you'll have to create all the information needed for all monitors you support (and fall back to "sub-pixel rendering disabled" for unknown monitors).

Note: As an alternative; you can let the user set the pixel geometry; but most users won't know and won't want the hassle, and the rest of users will set it wrong, so...

The second step is the make sure you're using the monitor's preferred resolution; because if you're not then the monitor will probably be scaling your image to make it fit and that will destroy any benefit of sub-pixel rendering. To do this you want to obtain and parse the monitors EDID or E-EDID data and try to determine the preferred resolution; then use the preferred resolution when setting the video mode. Unfortunately some monitors (mostly old stuff) either won't tell you the preferred resolution or won't have a preferred resolution; and if you can determine the preferred resolution you might not be able to set that video mode with VBE (on BIOS) or GOP or UGA (on UEFI), and writing native video drivers is "not without further problems".

The third step is the actual rendering; but that depends on how you're rendering what.

For advanced rendering (capable of 3D - textured polygons, etc) it's easiest to think of it as rendering separate monochrome images (e.g. one for red, one for green, one for blue) with a slight shift in the camera's position to reflect the pixel geometry. For example, if the pixel geometry is "3 vertical bars, with red on the left of the pixel, green in the middle and blue on the right" then when rendering the red monochrome image you'd shift the camera slightly to the left (by about a third of a pixel). However, this almost triples the cost of rendering.

If you're only doing sub-pixel rendering for fonts then it's the same basic principle in a much more limited setting (when rendering fonts to a texture/bitmap and not when rendering anything to the screen). In this case, if you cache the resulting pixel data and recycle it (which you'll want to do anyway) it can have minimal overhead. This requires that the text being rendered is aligned to a pixel grid (and not scaled in any way, or at abitrary angles, or stuck onto the side of a spinning 3D teapot, or anything like that).

I finally got it working by inverting the MSI-X table structure found on osdev.org. I decided to completely reinitialize the xHC after leaving the UEFI environment as it could leave it in an unknown state. Here's the xHCI code for anyone wondering the same thing as me:

Your load_idt function is written as a 32-bit function where the first parameter is passed on the stack. In the 64-bit System V ABI the first parameter is passed in register RDI. Use this instead:

1. Why does the "Message Address register contains fixed top of 0xFEE".

CPUs are like networking - packets with headers describing what their contents are, that are routed around a set of links based on "addresses" (which are like the IP address in a TCP/IP packet).

MSI is essentially a packet saying "write this data to that address", where the address corresponds to another device (the local APIC inside a CPU) and is necessary because that's what the protocol/s for the bus require for that packet/message type, and because that tells the local APIC that it has to accept the packet and intervene. If the address part is wrong then it'd just look like any other write to anything else (and wouldn't be accepted by the local APIC and wouldn't be delivered as an IRQ to the CPU's core).

Note: In theory, for most (Intel) CPUs the physical address of the local APIC can be changed. In practice there's no sane reason to ever want to do that, and if the phgysical address of the local APIC is changed I think the standard/original "0xFEE..... " address range is still hard-wired into the local APIC for MSI acceptance.

1. What are the RH, DM and XX bits in the Message Address register?

The local APIC (among other uses) is used by software (kernel) on one CPU to send IRQ/s to other CPUs; called "inter-processor interrupts" (IPIs). When MSI got invented they simply re-used the same flags that already existed for IPIs. In other words, the DM (Destination Mode) and most of other bits are defined in the section of Intel's manual that describe the local APIC. To understand these bits properly you need to understand the local APIC and IPIs; especially the part about IPI delivery.

Later (when introducing hardware virtualization) Intel added a "redirection hint" (to allow IRQs from devices to be redirected to specific virtual machines). That is described in a specification called "Intel® Virtualization Technology for Directed I/O Architecture Specification" (available here: https://software.intel.com/content/www/us/en/develop/download/intel-virtualization-technology-for-directed-io-architecture-specification.html ).

Even later, Intel wanted to support systems with more than 255 CPUs but the "APIC ID" was an 8-bit ID (limiting the system to a max. of 255 CPUs and one IO APIC). To fix this they created x2APIC (which changed a bunch of things - 32-bit APIC IDs, local APIC accessed by MSRs instead of physical addresses, ...). However, all the old devices (including IO APICs and MSI) were designed for 8-bit APIC IDs, so to fix that problem they just recycled the same "IRQ remapping" they already had (from virtualization) so that IRQs with 8-bit APIC IDs could be remapped to IRQs with 32-bit APIC IDs. The result is relatively horrible and excessively confusing (e.g. a kernel that wants to support lots of CPUs needs to use IOMMU for things that have nothing to do with virtualization), but it works without backward compatibility problems.

1. How does this work with the lAPIC? Basically, how does it trigger interrupts in the lAPIC.

I'd expect that (for P6 and later - 80486 and Pentium used a different "3-wire APIC bus" instead) it all uses the same "packet format" (messages) - e.g. that the IO APIC sends the same "write this data to this address" packet/message (to local APIC) that is used by IPIs and MSI.

Is it some kind of inter-processor interrupt from outside the CPU?

Yes! :-)

I finally got it. My kernel had the following code:

Your code panics because as_str() only returns Some, if there is no arguments. So when you immediately unwrap() it will panic, for instances where you have arguments to be formatted.

Get the formatted string, if it has no arguments to be formatted.

This can be used to avoid allocations in the most trivial case.

– std::fmt::Arguments::as_str() docs

Instead you can use args.to_string() instead of args.as_str().unwrap(), to format it into a String. So it actually formats regardless of whether there is any arguments or not.

I did not knew that it was a simple answer! I just had to dref(*) the GDT as it was lazy static and that solved everything :D

You're cross-compiling to a different architecture (i686-elf) than whatever you're running on—the $TARGET mentioned in the question. gdb will have to be linked with libraries which are built for that architecture.

Debian provides ncurses packages which run on the current architecture, but does not provide a suitable package for the cross-compiled application. So you get to do this for yourself.

When cross-compiling ncurses, you'll have to keep in mind that part of it builds/runs on the current architecture (to generate source-files for compiling by the cross-compiler). That's defined in the environment as $BUILD_CC (rather than $CC), as you might see when reading the script for the mingw cross-compiling. There's a section in the INSTALL file (in the ncurses sources) which outlines the process.

There's no tutorial (that would be off-topic here anyway), but others have read the instructions and cross-compiled ncurses as evidenced by a recent bug report.