There are several aspects to consider to answer your question.
The x86 architecture is backwards-compatible with the first CPU of the line, the 8086 (and its sibling, the 8088). What this means is that, when a modern Intel (or AMD) processor boots up, it starts in a mode which is compatible with the 8086 — if the motherboard's BIOS support is good enough, you can still boot MS-DOS on a brand-new PC (albeit not from a floppy disk!). (Presumably you could also boot CP/M-86, but I haven't tried that. Other 16-bit operating systems, such as OS/2, Coherent or Xenix, are more demanding and tend not to work — Fun with virtualization goes into the specifics). The 8086 and 8088 are 16-bit CPUs, inasmuch as they process data internally 16 bits at a time. As newer CPUs introduced wider internal data busses, new modes were added to support them, so you get 32-bit binaries and now 64-bit binaries, and it's even possible to mix and match. So a modern, 64-bit x86-compatible CPU can still run 16-bit binary code, at least in some modes (64-bit mode, or "long mode", doesn't support real-mode 16-bit code; it's possible to work around this using VT-x).
Running an application doesn't just require CPU support though, it also requires operating system support. So you can't just take a 16-bit DOS or Windows binary and run it on a Linux system, or even on a Windows 10 system — you need some sort of emulation layer, not for the CPU, but for the operating system services and virtualised hardware. This is where tools such as NTVDM, DOSBox or Wine come in.
What would it mean to run an 8-bit binary on an x86 CPU? On the CPU side, the closest 8-bit CPU is the 8080, but the 8086/8088 is different enough that it's not binary-compatible with the 8080; so you can't directly run an 8080 binary on an 8086, let alone on a more modern x86 CPU. On the operating system side, the best you could hope for would be that your application was built for CP/M; so you'd need some sort of CP/M-compatible layer (or perhaps CP/M-86 or DOS which was somewhat backwards-compatible).
As mcleod_ideafix points out, the x86 is source-code compatible with the 8080, i.e. the 8086 supports all the features of the 8080 and the Intel assembler mnemonics for the 8080 can be (in most cases) mechanically converted to equivalent 8086 assembly. But you'd still need to adapt the application to the target operating system, as well as the new target CPU. (Stephen P. Morse's 8086 history covers this in more detail.)
So in summary, you can't take an 8-bit binary and run it directly on an x86 processor. If you're careful, you may be able to rebuild an 8-bit 8080 assembly language program for the 8086, and run it under CP/M-86 or DOS. Thanks to the x86 architecture's support for 8-bit operations, you can write an 8-bit style application (i.e. using only 8-bit arithmetic and logical operations, but 16-bit pointers) and run it on a 16-bit operating system (the BIOS supports this rather well, as does DOS). But to me this isn't quite the same as the 16-bit and 32-bit support on modern 64-bit systems, because the 16-bit nature of the architecture leaks into its 8-bit support: for example, 8-bit DIV always divides the 16-bit AX, which means you can't simply pretend AL and AH are separate 8-bit registers unless you avoid DIV, MUL etc. entirely.
QEMU itself doesn't emulate any 8-bit CPUs. There are many 8-bit emulators for modern systems though, some including the operating environment — examples include Stefan Tramm's 8080 CP/M emulator, the Toledo 8080 emulator, Z80pack...