Uefi Hybrid With Csm Vs Uefi Native Without Csm

[Prisc Chandola]

I have three partitions on the primary drive in my computer. The drive is formatted to GPT and the three partitions are one ESP (EFI System Partition) and two Primary (Windows 10/Windows 7 each one). There are three options for "Boot Mode" in the motherboard settings, "Legacy", "UEFI" and "UEFI with CSM".

If it's set to "Legacy", the computer tells me "No operating system found". That's correct. If it's set to "UEFI with CSM", both Windows boots normally. If it's set to "UEFI", then only Windows 10 can boot. From the safe boot log I can see Windows 7 gets stuck at classpnp.sys.

I plugged in another drive in MBR, containint two partitions. One primary active with FAT32 and another primary with NTFS, with another Windows 7 installed. It seems I however just can't make it boot if the MB settings is set to either "UEFI" or "UEFI with CSM", but it boots perfectly when set to "Legacy". If I edit the BCD in the EFI partition on the primary disk to add an entry for this experimental Windows 7 installation, it boots under "UEFI with CSM", but still gets stuck at classpnp.sys in "UEFI".

I have another computer with a MSI B85 motherboard that has a switch named "CSM". If it's enabled then there are two options available in "Boot Mode", "UEFI" and "Legacy". If it's disabled then Boot Mode is locked to UEFI. In that case "UEFI" mode with CSM enabled allows Windows 7 to boot, but it won't boot with CSM disabled.

"UEFI with CSM" usually means mixed mode in which both native (UEFI) and CSM-based (BIOS) boot is available. The boot menu will show a mix of native UEFI boot entries and CSM "bootable disk" entries in this case.

However, one important side effect of disabling CSM is that it'll allow certain UEFI-only features to be activated (such as "fast boot"), at the same time preventing some BIOS-only features (such as PCI option ROM support).

As you've noticed, the Compatibility Support Module can be required by the operating system for UEFI boot, not just legacy boot. This is the case for Windows 7. There are in fact name-brand computers that even lack a CSM and cannot boot Windows 7 at all.

I've also noticed having it enabled/disabled can have other effects, like changing which monitor (in a multi-monitor system) or screen resolution is used during boot. It is also, in my experience, required to turn it off to do UEFI network boot. Otherwise, only the legacy network boot firmware is accessible, which cannot boot an operating system in UEFI mode.

People really make a mess out of what is still always just a UEFI protocol/driver (the word "BIOS" being used simultaneously as a shorthand for "firmware type", "OpROM technology" and "MBR boot" doesn't help though).

With this said, I wouldn't know about your laptop but if it's aged similarly to your 2013 LGA 1150 motherboard, then it might have been carrying an equally as old firmware like Aptio 4 (which was itself coming from an era of transition). In turn that could contain some leftover from the time when UEFI firmware was forced to boot BIOS-like-only.

Hence the tri-state toggle (each setting very broadly corresponding to an UEFI class) despite the fact that it doesn't really make sense to add a choice that is a strict subset of the capabilities of CSM proper. I.e. again, the thing cannot exist without or outside of UEFI (check the whitepaper I mention in the first link for more details).

But for some reason your OEM decided to re-frame its logic to have cut and dried "separate" boot tracks, even though the thing is not technically "exclusive" to any (well, on linux that is at least.. Windows is a little can of worms). Maybe they wanted to avoid as much as possible users unwittingly booting the old fashioned way? Or perhaps they wrote the setup menu code with the bare minimum of extra services to support W7 in mind, for those systems sold close to the W8 release date and dreaming of an expedite upgrade path?

Because that's the other factor that you are missing out: W7 isn't going to boot (out of the box at least) in a pure UEFI environment. It's either a full legacy installation, or an UEFI one tied to CSM (mostly for video output purposes, it's funny that your third point was already pretty close to the hacks to mix up partition schemes). Oh, and alas classpnp.sys usually means next to nothing.

So.. long story short, from what you are telling here, "UEFI with CSM" is therefore simply CSM except it has been made just an aid for native UEFI-aware OSs rather than the normal "full suite" of BIOS emulation (unclear if just out of dropping the MBR parsing, because of only accepting UEFI executables, or due to gutting all the extra code after "setting up BIOS interrupt calls and the legacy VBIOS").

In a sense it does exactly what it's written on the tin, but in another it's a pretty specious moniker too (also, please, your desktop has the option named LEGACY+UEFI which would have spelt it already clear).

You will see online that many people refer to it as UEFI BIOS. Strictly speaking, this is wrong, because BIOS is not a generic term for firmware. BIOS is a specific firmware for IBM compatible PC, so we should call the newer firmware UEFI.

OptionROM comes with BIOS. optionROM has a size limitation of 64KB. It can not be loaded on hard disk, or USB drive. In addition, OptionROM has to be fit for every hardware. So if you change your hardware, you must also change the code of OptionROMs.

BIOS still provides some services after it has finished initializing the hardware and POST. UEFI is pre-boot and boot time only. After initializing the hardware, UEFI passes the control completely to the operating system.

BIOS allows only one boot loader, which is stored in the master boot record. UEFI allows you to install multiple bootloaders in the EFI partition on the hard disk. This means you can install Linux and Windows on the same hard disk in UEFI mode without wiping out the Grub boot loader or the Windows boot loader.

Note that hybrid mode is not native UEFI mode. If you really want to use UEFI, then you must enable UEFI only and do not enable BIOS. Computers have faster boot time in native UEFI mode because the BIOS does not need to be loaded.

UEFI specification requires the boot loader architecture matches the firmware architecture to reduce problems. In other words, 32-bit UEFI can only run a 32-bit boot loader and 64-bit UEFI can only run a 64-bit boot loader. However, you can run 64-bit OS with 32-bit UEFI and 32-bit OS with 64-bit UEFI.

Edit: Another thought - the 9500 GT doesn't support UEFI. Can OVMF still work with it WITHOUT UEFI support on the GPU ?Perhaps my 1070 would work better. Hopefully one of the gurus out there could give me some pointers

Running a fury on the guest and a 1070 on the host-- previously I ran a 7970 on the guest with a shunted UEFI bios, and set one up for a friend where I bought a sapphire card that had native UEFI support. Never tried to get older hardware working on Tianocore, but you may have more luck with a seabios setup given how old your cards are.

I'm a bit confused at all this information. The general consensus is that IOMMU for Ryzen is a no-go, but is it essentially up to motherboard manufacturers to push out better grouping in their EFI updates, or is this something that's gimped in the chips themselves?

IOMMU Works. It just doesn't as work as well as we might like. Basically, it isn't isolating every device into its own IOMMU Group. Instead the group seems to be determined by where that pcie port comes from - is it from the cpu, or the chipset? Everything off the chipset gets shoved into its own group.

I saw that, thanks for the info. Are IOMMU groups assigned by the board's EFI or are they hard wired though? Is it possible for board manufacturers to fix the groups in firmware so the patches aren't needed?

I haven't seen a screenshot yet on the group for a m.2 NVME SSD. The reason I want to check is because it is technically possible to install an m.2 to pcie adapter, with a riser cable, to install another GPU in that port. If it is not pert of the bifurcated x16 group that could be a new approach. My biggest fear is that some video cards draw a lot of pcie power, more than m.2 is probably capable of... however...

I happen to have a gigabyte ax370 gaming 5, and as an extra bonus it has u.2, which doesn't supply power, but instead uses a sata or molex for power, thus I don't have to worry about overloading my m.2 port. So, if it is in a different group...

Since the u.2 / m.2 port is direct to the CPU it should be possible to prioritize it's initiation too, or if not use that as the pass through port. Anyways, does anyone have an m.2 pcie ssd that can check the grouping for the port. I sadly don't.

So i guess the question is can we initialize the "m.2" gpu over the pcie x16 one? If yes, great, but probably not. it is going through the chipset rather than direct so i suspect it will be no different than using the x4 2.0 slot.

No, this is not a good idea with this type of adapter. I have one, but they are limited to 25w even with the power adapater. Graphics card may use up to 75 watts, which requires a special type of adapter.

My true goal is to be able to split my crossfire setup in half and pass 1 though, but without proper isolation that will be impossible. ACS is no hope for me. My next best is to install my passive cooling nvidia card in a 4x slot and pass through both AMD cards, and hopefully iommu crossfire works?

I think whats going on, as described on other forums, is that when linux boots using the 1070 it shadows the 1070's rom with its own boot rom. It then writes to this shadow rom, which confuses UEFI. The solution is to create a rom file for the graphics card, and use that in the VM instead of passing through the one from the host OS.

I plan on doing this, but need to rip the Rom from my 1070 - the stock rom as downloaded elsewhere includes a hybrid BIOS boot image, and that seems to be tripping up OVMF. I should be able to download the rom from the 1070 when it is running via x4 pcie 2.0 though.

c80f0f1006