The asker has a hobby kernel that boots cleanly under QEMU but triple-faults on real hardware right around mov cr0, eax — the instruction that flips the CPU into protected mode. They're loading the kernel at 0x7E00 and chained through Ventoy from a custom ISO.

Why this is the canonical hobby-OS trap. QEMU is forgiving in ways real silicon is not. It tends to start with sane defaults: A20 already enabled, segment caches in a reasonable state, BIOS data areas untouched, and a GDT that "just works" even if your descriptors are slightly wrong. Real hardware, especially via a UEFI-CSM path that Ventoy uses, hands control off in a state that is technically legal but full of footguns.

Likely root causes, ranked by how often I've seen them bite people:

• A20 line still gated. QEMU enables it; many real BIOSes do not. The first access above 1 MiB after enabling paging or jumping into the kernel wraps and faults. Test with the keyboard controller method or the fast A20 port (0x92), and verify by writing/reading across the 1 MiB boundary.
• Invalid or misaligned GDT. The GDTR must point to a structure that survives the cr0 write. If your GDT lives in a sector you didn't actually load, or your descriptors have the wrong granularity/limit, the very next far jump triple-faults. QEMU sometimes papers over a stale code segment cache; real CPUs do not.
• Sectors not actually loaded. BIOS int 13h AH=02h has a per-call sector limit (typically 0x7F) and CHS quirks on real disks vs. QEMU's flat image. Use the LBA extension (AH=42h) and verify CF and AL after the call.
• Stack pointer in BIOS-owned memory at 0x7C00-ish. QEMU shrugs; real BIOS code may have left data there.
• Ventoy-specific: it loads your ISO via a memdisk-like shim and hands off in a state different from a pure El Torito boot. The boot drive number in dl may not be what you expect.

Sketch of a debugging plan:

• Before mov cr0, eax, write a recognizable byte to 0xB8000 (text VGA). If you don't see it on hardware, you never got there.
• Immediately after the cr0 write and the far jump, write a different byte. Now you know which side of the transition died.
• lgdt then dump the GDT bytes to screen and compare against your assembled image — confirms the loader actually copied them.
• Force A20 via port 0x92 unconditionally before enabling protected mode.

Gotcha: "It works in QEMU" is not evidence of correctness — it's evidence that QEMU's defaults masked your bug. Always test under Bochs with -q and on at least one real machine before declaring a boot sequence done.