How to generally enter virtual 8086 mode?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
rdos
Member
Member
Posts: 3296
Joined: Wed Oct 01, 2008 1:55 pm

Re: How to generally enter virtual 8086 mode?

Post by rdos »

Ethin wrote:Uh... Once ACPI 6.4 gets supported by firmware -- which is happening pretty quickly, I'm pretty sure EDK II/OVMF already supports a large majority of it -- you bet that I'll be using it and I'm pretty sure other OSes will switch to it too when supported. It makes AP initialization significantly easier -- no need to mess about with assembly language or any of that stuff, just point the AP at a function to run and boom. I imagine it might also speed up OS startup by small margins too -- it ultimately means that, since most of the work is already done for you, all you have to do is swap out the page tables and your good to go. If I remember right its also architecture independent, unlike previous methods, meaning you can do that same strategy on any architecture that aCPI supports. But I might be wrong on that last point.
I find ACPI to mostly be useless stuff, and I only have a (huge) driver for it on APIC platforms because I need it to identify IRQs. With older computers with PIC & PIT, I don't load the ACPI driver at all and rely on my own drivers for what hardware is present.

The most interesting potential use of ACPI is for handling processor states & boosts, but the ACPI objects exported by many mainboards won't tell you how to do that, and major OSes (Windows & Linux) use their own processor drivers, which probably explains why ACPI doesn't have decent processor objects. So, I also have my own "processor" drivers and ignore ACPI.

So, no, I don't share your enthusiasm for ACPI, and find it to be a rather useless firmware component that too often have serious bugs in the scripts that make simpler ACPI implementations freak out.
Octocontrabass
Member
Member
Posts: 5563
Joined: Mon Mar 25, 2013 7:01 pm

Re: How to generally enter virtual 8086 mode?

Post by Octocontrabass »

rdos wrote:Certainly, but it also depends on major OSes adopting to use this or later ACPI versions. I see quite a bit of lag in this area.
Adopting UEFI took a while too, but here we are.
thewrongchristian
Member
Member
Posts: 426
Joined: Tue Apr 03, 2018 2:44 am

Re: How to generally enter virtual 8086 mode?

Post by thewrongchristian »

nullplan wrote:Meaning that a processor that doesn't let you turn off long mode would be able to cut out quite a lot of weird stuff nobody ever needs (task gates, real mode address creation), and all of those transistors could then be reused to do something useful instead.
Would it really cut out much in terms of transistors, though?

The vast, vast, vast majority of transistor budget is in caches.

I would be surprised if cutting support for all the strangeness of real mode and task gates would amount to anything more than a tiny fraction of a percent of transistors/floorplan. The method of emulating those features is likely largely the same as it has been seen PPro days, and ripping would require much validation.

Xeon Phi (previously Larrabee) are based on Pentium in-order cores, widened to 64-bit, and including SMT to better utilize pipeline resources, but even those still support real-mode. If Intel can't be bothered ripping out real-mode in those, I don't see them doing it in mainstream CPUs either.
Octocontrabass
Member
Member
Posts: 5563
Joined: Mon Mar 25, 2013 7:01 pm

Re: How to generally enter virtual 8086 mode?

Post by Octocontrabass »

I suspect the driving force behind removing legacy x86 features is validation. You don't have to ensure task gates work correctly in every possible configuration if your CPU doesn't allow switching out of long mode.
Ethin
Member
Member
Posts: 625
Joined: Sun Jun 23, 2019 5:36 pm
Location: North Dakota, United States

Re: How to generally enter virtual 8086 mode?

Post by Ethin »

That and there's just no point in keeping them. I doubt that the microcode for 32-bit/16-bit code has been touched in a decade if not more. The compatibility stuff just complicates every stage of the boot process and slows everything down. The boot process would probably be considerably faster if BIOSes just started in 64-bit mode with a processor-defined paging table, and then they just replaced that with their own and initialized everything as normal. If the compatibility was removed nobody would need to worry about that. Not to mention pretty much nobody uses real mode code anymore. I mean, FreeDOS exists but I'm pretty sure the number of people who use that are extremely tiny. And even that will be obsolete soon when UEFI finishes replacing BIOSes.
nullplan
Member
Member
Posts: 1790
Joined: Wed Aug 30, 2017 8:24 am

Re: How to generally enter virtual 8086 mode?

Post by nullplan »

Ethin wrote:I mean, FreeDOS exists but I'm pretty sure the number of people who use that are extremely tiny.
Well, I've used it and I'm average height *badumm-tss*. But yes, the only reasons I ever had to run FreeDOS were to run DOS software in an emulator, but that is just DOSBOX, and to update the BIOS, but these days, BIOSes frequently have an updater inside and don't require another OS.
Carpe diem!
kzinti
Member
Member
Posts: 898
Joined: Mon Feb 02, 2015 7:11 pm

Re: How to generally enter virtual 8086 mode?

Post by kzinti »

nullplan wrote:Well, I've used it and I'm average height *badumm-tss*.
Tss tss...

Nice... lol!
rdos
Member
Member
Posts: 3296
Joined: Wed Oct 01, 2008 1:55 pm

Re: How to generally enter virtual 8086 mode?

Post by rdos »

Ethin wrote:That and there's just no point in keeping them. I doubt that the microcode for 32-bit/16-bit code has been touched in a decade if not more. The compatibility stuff just complicates every stage of the boot process and slows everything down. The boot process would probably be considerably faster if BIOSes just started in 64-bit mode with a processor-defined paging table, and then they just replaced that with their own and initialized everything as normal. If the compatibility was removed nobody would need to worry about that. Not to mention pretty much nobody uses real mode code anymore. I mean, FreeDOS exists but I'm pretty sure the number of people who use that are extremely tiny. And even that will be obsolete soon when UEFI finishes replacing BIOSes.
I don't think UEFI has speeded up the boot process, rather the opposite. There now are megabytes of code, while the BIOS solution was much more compact (and probably a lot faster).

And I don't think the OS boot process will be any faster because it can skip the real mode part. This code typical executes in microseconds, while the bloat of UEFI is a lot more substantial.
nullplan
Member
Member
Posts: 1790
Joined: Wed Aug 30, 2017 8:24 am

Re: How to generally enter virtual 8086 mode?

Post by nullplan »

rdos wrote:I don't think UEFI has speeded up the boot process, rather the opposite. There now are megabytes of code, while the BIOS solution was much more compact (and probably a lot faster).
Have you measured? All my BIOS machines have required a minimum of 30 seconds to boot, from a 486 all the way up to an Athlon 64. That's insane. The last BIOS machine was literally 100x faster (on one core) than the first, and the code took about the same time. Whereas all my UEFI machines took about 10 seconds. I don't even need to measure it, that difference I can just see and feel.
Carpe diem!
rdos
Member
Member
Posts: 3296
Joined: Wed Oct 01, 2008 1:55 pm

Re: How to generally enter virtual 8086 mode?

Post by rdos »

nullplan wrote:
rdos wrote:I don't think UEFI has speeded up the boot process, rather the opposite. There now are megabytes of code, while the BIOS solution was much more compact (and probably a lot faster).
Have you measured? All my BIOS machines have required a minimum of 30 seconds to boot, from a 486 all the way up to an Athlon 64. That's insane. The last BIOS machine was literally 100x faster (on one core) than the first, and the code took about the same time. Whereas all my UEFI machines took about 10 seconds. I don't even need to measure it, that difference I can just see and feel.
I think your observation mostly is related to amount of memory, not speed of the boot process. My Threadripper PC with 128 GB of memory has considerably longer boot times than more normal PCs with lesser physical memory. On 386 & 486 systems it was customary to test memory extensively, and often there were options in BIOS to use fast testing to speed up booting. My guess is that UEFI machines typically do no testing at all of installed memory. That doesn't mean they boot fast, only that they sacrifice reasonable testing of memory to boot faster.

Edit: Tested with two machines here.

The first one is a rather dated dual-core AMD (800 MHz). It has 8 GB of memory and boots in about 5 seconds using BIOS.
The second one is a eight core AMD laptop a few years old. It also has 8 GB of memory and boots in about 6 seconds using EFI.

The EFI machine has a considerably faster processor, and also a considerably faster SSD disc.

The EFI loader loads a 60kB large EFI image (that's rather small compared to what Windows uses), and a 8kB OS loader. The BIOS loader loads a bit over 10 sectors from disc to get to the same stage. It's easy to see how this affects performance on a slow disk.
Ethin
Member
Member
Posts: 625
Joined: Sun Jun 23, 2019 5:36 pm
Location: North Dakota, United States

Re: How to generally enter virtual 8086 mode?

Post by Ethin »

UEFI is a necessity though. It introduces a lot of new features and possibilities that BIOS never did because of the extreme constraints that were placed upon it. And have you actually confirmed that UEFI sacrifices the testing of RAM? I'm pretty sure it doesn't.
rdos
Member
Member
Posts: 3296
Joined: Wed Oct 01, 2008 1:55 pm

Re: How to generally enter virtual 8086 mode?

Post by rdos »

Ethin wrote:UEFI is a necessity though. It introduces a lot of new features and possibilities that BIOS never did because of the extreme constraints that were placed upon it. And have you actually confirmed that UEFI sacrifices the testing of RAM? I'm pretty sure it doesn't.
UEFI doesn't introduce anything useful for me. UEFI will typically require me to build a 64-bit .efi file that can load a boot-loader that can turn off long mode & paging and restart the process of building the execution environment. That's not a new feature, it's an obstacle. Some EFI implementations fail to load the OS image.

In addition to that, I must setup the video mode in EFI, and so cannot use the video BIOS for this. That's not a feature, more like an obstacle too.

If that wasn't enough, I cannot tell UEFI to place my OS image at a fixed physical address, and so I need to guess were it is safe to place it. With BIOS, I can load it anywhere I want. This is not a feature, rather yet another obstacle.

Some OSes can lock-down UEFI so my OS cannot boot. That's not a feature for me, or for the typical developer, rather something Microsoft likes so nobody can boot any other OS.

It should also be possible to install boot loader on the EFI partition, but the problem is that there is no standard as to what startup EFI files are called at boot time, and so often you will find Windows still boots even when you have replaced the proposed 64-bit loader bootx64.efi.

So, I definitely prefer BIOS boots when this is possible since it always works, much unlike the EFI environment that has lots of potential pitfalls.
Octocontrabass
Member
Member
Posts: 5563
Joined: Mon Mar 25, 2013 7:01 pm

Re: How to generally enter virtual 8086 mode?

Post by Octocontrabass »

rdos wrote:If that wasn't enough, I cannot tell UEFI to place my OS image at a fixed physical address, and so I need to guess were it is safe to place it. With BIOS, I can load it anywhere I want.
Why do you want to place your OS image at a fixed physical address? (Plus, BIOS and UEFI both provide a memory map that tells you exactly where you can place things.)
rdos wrote:often you will find Windows still boots even when you have replaced the proposed 64-bit loader bootx64.efi.
That's because bootx64.efi is the fallback bootloader, used only when there are no other bootloaders installed. You're supposed to install your own bootloader within your own subdirectory and create a boot variable that refers to it.

Unfortunately, some broken UEFI implementations will always launch the Windows boot manager if it's present, ignoring boot variables and the fallback bootloader. In these cases, you'll have to either move it elsewhere (and update the Windows boot variable to point to the new location) or replace it with your own bootloader.
rdos wrote:So, I definitely prefer BIOS boots when this is possible since it always works, much unlike the EFI environment that has lots of potential pitfalls.
BIOS has lots of its own pitfalls; you only prefer it because you already know where they are.
Ethin
Member
Member
Posts: 625
Joined: Sun Jun 23, 2019 5:36 pm
Location: North Dakota, United States

Re: How to generally enter virtual 8086 mode?

Post by Ethin »

rdos wrote:
Ethin wrote:UEFI is a necessity though. It introduces a lot of new features and possibilities that BIOS never did because of the extreme constraints that were placed upon it. And have you actually confirmed that UEFI sacrifices the testing of RAM? I'm pretty sure it doesn't.
UEFI doesn't introduce anything useful for me. UEFI will typically require me to build a 64-bit .efi file that can load a boot-loader that can turn off long mode & paging and restart the process of building the execution environment. That's not a new feature, it's an obstacle. Some EFI implementations fail to load the OS image.

In addition to that, I must setup the video mode in EFI, and so cannot use the video BIOS for this. That's not a feature, more like an obstacle too.
These are obstacles for you in particular. Your OS uses ancient, outdated technologies that no modern OS uses, which is why your running into these problems. UEFI has lots of advantages for me: I get to write less assembly, I can implement nice things like braille display HID support as early as the very point when the USB hardware is initialized by the firmware (try doing that in BIOSes, I guarantee you you won't be able to do it), and a lot is standardized that isn't in a BIOS system. Before UEFI came along any form of accessibility -- even the most primitive stuff -- was a pipe dream and it was just known that such a thing would never happen, but it is no longer a pipe dream and can be done with what UEFI provides. It helps that the vast majority of HW vendors *don't* reimplement UEFI and just use EDK II (although a customized form of it). Sadly, many people don't think of accessibility during development and only as an afterthought, which I hope changes soon because that's something that I shouldn't have to make into a legal requirement to get people to do. Anyway. I find UEFI to be a blessing a lot more than a curse, considering what it allows me to do. Secure boot abuse is a problem, but I appreciate the fact that I can set up my own keys and lock down the boot process to things only I want to boot, and I can then reinforce that with extra restrictions of my own when my kernel is launched. I appreciate that I don't have to care about the video mode; I always will have an LFB and that means I don't have to add extra code for text mode unless I want it, and if I want that I might as well just write a GPU driver. I never have to reconstruct any boot environment because I don't care about segments when paging gives me all the benefits of segments and then some.
rdos
Member
Member
Posts: 3296
Joined: Wed Oct 01, 2008 1:55 pm

Re: How to generally enter virtual 8086 mode?

Post by rdos »

Octocontrabass wrote:
rdos wrote:If that wasn't enough, I cannot tell UEFI to place my OS image at a fixed physical address, and so I need to guess were it is safe to place it. With BIOS, I can load it anywhere I want.
Why do you want to place your OS image at a fixed physical address? (Plus, BIOS and UEFI both provide a memory map that tells you exactly where you can place things.)
Because it is convenient. With BIOS, it pretty safe to place an OS image just above the HMA area (0x110000). The BIOS memory map primarily is useful so the OS knows where there is working physical RAM. With older 386 hardware, I don't think you can rely on the BIOS memory map function to even exist.

The UEFI memory map, OTOH, is cluttered with UEFIs own memory usage that is not standardized. It's possible that UEFI could place itself or some data just above HMA (although, I've not yet seen any implementation that does so).

Of course, the primary reason I want to place my OS image at a fixed address is because it must be below 4G. A 64-bit EFI might place it above 4G. I also have reserved a physical address range a bit higher (0x120000) that is aimed to be used to switch between long mode and protected mode. I need this since that process requires turning off paging.

Actually, the boot process itself requires the loader to be placed at a fixed address too, for exactly the same reason. To get back to protected mode, there is a need to define a new GDT, turn off long mode (which ends up in non-paged mode) and init protected mode. This process is much easier to do when the image is loaded at a fixed address.
Octocontrabass wrote:
rdos wrote:often you will find Windows still boots even when you have replaced the proposed 64-bit loader bootx64.efi.
That's because bootx64.efi is the fallback bootloader, used only when there are no other bootloaders installed. You're supposed to install your own bootloader within your own subdirectory and create a boot variable that refers to it.

Unfortunately, some broken UEFI implementations will always launch the Windows boot manager if it's present, ignoring boot variables and the fallback bootloader. In these cases, you'll have to either move it elsewhere (and update the Windows boot variable to point to the new location) or replace it with your own bootloader.
How to change boot variables is undocumented and not supported by the UEFI interactive interface.

Anyway, a safe way to remove Windows appears to be to repartition the disc, as this appears to make UEFI so confused so it uses bootx64.efi to boot regardless of the hidden settings Windows once created.
Post Reply