I would think the articles you've read were most likely about the Virtual 8086 Mode introduced with the 386.
Here a host OS (running at privilege 0) would create a standard protected process, but mark it as VM86 when starting. In turn the process will be restricted to real mode addressing (16 bit segment and offset) and a 1 MiB address space.
Despite the naming (8086 mode) the code is not restricted to pure 16 bit. The CPU acts still as 386 enabling use of all operations with 32 bit registers or operands, by applying the usual prefixes. Restrictions comes only due operation encoding (like only BX, BP, SI and DI can be used for addressing) and address calculation. Any offset generated by an address calculation (like base plus index) must be result in a 16 bit value — otherwise a protection fault is issued (*1)
Virtual 8086 mode is essentially like the way a 386 comes out of reset, except it provides no way to access an virtual memory functions. All 'real' address generation is restricted to 20 bit, all critical instructions (*2) and I/O (*3) would be trapped, avoiding any break out attempt while allowing the host OS to redirect/emulate all hardware reaction.
In theory it would have been possible to load any arbitrary 16 bit (8086) OS and have it run flawless. For practical reasons higher level abstractions were preferred. After all, a 16 MHz 386 might be fast, but emulating byte wise disk access would it pull well down to C64/1541 level :))
VM86 was introduced with the 80386 and is still available today. Next to all OS adapted to 80386 and later supported this, starting with DR Concurrent DOS and Windows /386 (*4). All Windows supported it for DOS/16 bit programs, as well as OS/2 and Linux (for DOSEMU).
So unlike virtualization that 'multiplies' the existing, 'real' CPU with all its features, VM86 presents a limited CPU model for virtualized tasks.
The OS-Dev Wiki provides two pages to further dive into this interesting mode:
*1 - The VM handler can of course relieve this by emulating a real mode address wrap. This may of course result in a hefty performance penalty ... as with an dirty code using fringe cases.
*2 - Trapped instructions are
- PUSHF/POPF - To avoid escaping the VM and emulation if flag status
- CLI/STI - To manage interrupt forwarding (and avoid locking the machine)
- INT - So the Host OS can catch and emulate software interrupts
- IRET - Again to avoid leaving the VM (IRET loads the EFLAGS rgister)
*3 - I/O privilege can be made available, which is quite handy when using a ROM BIOS from protected mode.
*4 - Yes, that's Win 2.1, so way before Win 3.x