On 09/07/2015 20:33, Andy Lutomirski wrote: > On Wed, Jul 8, 2015 at 10:59 PM, Ingo Molnar <[email protected]> wrote: >> >> * Ingo Molnar <[email protected]> wrote: >> >>>> Without something like that, we'll be in the awkward position of having >>>> some >>>> of the selectors (DS, ES, FS, and GS) in both the normal pt_regs slot and >>>> in >>>> the extended hardware frame during execution of normal vm86-unaware kernel >>>> code. If, on the other hand, we copied the selectors across in >>>> enter_from_user_mode and prepare_return_from_usermode, then pt_regs would >>>> work >>>> normally even for tasks that are running in v8086 mode. >>>> >>>> regs->flags & X86_EFLAGS_VM will be true regardless, so all of the asm that >>>> decides to invoke those helpers should work fine. >>> >>> Btw., has anyone considered an entirely different approach: using KVM's >>> instruction emulator to emulate vm86 16-bit code execution? Basically the >>> vm86 >>> system call would be kept compatible, but fully emulated, the CPU never >>> enters >>> true 16-bit mode, just iterates pt_regs as if it had. >>> >>> This approach has four main advantages: >>> >>> - we could remove the fragile vm86 code from the entry code >>> >>> - it might even be faster for certain workloads than faulting in and out >>> all >>> the time and using ancient, fragile hardware mode of the CPU. (For >>> example it >>> could detect the VGA screen write patterns and accelerate them.) >>> >>> - it could be made to work on 64-bit as well, FWIIW >>> >>> - it would provide another angle of testing for the KVM emulator >> >> So there's a fifth advantage as well that I think needs to be stressed: >> >> - it's an _obviously_ much more secure design, as we only iterate >> user-space >> pt_regs and never truly touch any security relevant CPU state. The whole >> nested pt_regs and different hw frame entry complications would go away >> entirely. All CPU semantics would not be just assumed implicitly, but >> would >> be very much present in the CPU emulator and would be reviewable. >> > > Hmm. > > If we did this, I think I'd prefer a slightly more general approach. > First teach KVM to support a mode in which it's purely an emulator > (Paolo: how hard is this? It would also make testing the emulator > much easier).
This isn't hard, at least for Intel: make emulation_required() return true always (and fix the fallout). However, it's not necessary. The emulator is designed to be independent from the rest of KVM. At some point I think Avi was testing it in userspace (or planning to do so). So you would just move it from arch/x86/kvm to arch/x86/emulate. The obvious downside is that the emulator isn't really designed for speed. In KVM it's currently 1000-1500 times slower than the real thing. Even if you modified it to remove the KVM overhead (vm86 is just running ring 3 code; no interrupts and no pagetables to walk), it probably would take 300-500 cycles to execute one instruction. But it's doable. > The big downside of that, or of writing a more ad-hoc emulator, is > understanding what the semantics of all the weird vm86plus stuff is > supposed to be in the first place. Do you mean VIF/VIP and the other vm86 mode extensions? Or is vm86plus something in Linux? Paolo > It's completely undocumented and > it's not at all obvious what it's all supposed to do. This sounds > like a fairly large project. > > I think I'd rather get all the distros to turn vm86 off and let it > slowly die in a dark corner. After all, dosemu and vbetool both > already contain emulators that seem to work, and dosbox (which is, by > all reports, better than dosemu) never used vm86 in the first place. > > --Andy > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
