Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN

[Ingo Molnar <mingo@kernel.org>]

* Andy Lutomirski <luto@amacapital.net> wrote:

> >> I look forward to it.
> >>
> >> However: I imagine that, if you do this, you may need to be quite careful 
> >> about an x86_32-ism.  Currently, if you have a pt_regs pointer for the 
> >> current entry and user_mode(regs) returns true, then regs == 
> >> current_pt_regs().  If you let user mode run with EFLAGS.VM set with the 
> >> normal tss.sp0, then this will no longer be true, as the extra-long 
> >> entry-from-v8086 frame will shift pt_regs by a few bytes. I don't know 
> >> whether this matters, but I can imagine it causing do_signal to explode.  
> >> *shudder*
> >
> > I am aware that pt_regs is in a fixed location on the stack.  What I plan to 
> > do is increase the padding at the top of the stack if VM86 is configured, to 
> > reserve space for the extra segment registers.  Then it will move tss.sp0 up 
> > 16 bytes when entering vm86 mode so that the longer IRET frame is in the right 
> > place.
> >
> 
> Hmm, should work.
> 
> I wonder if the right way to do this is to set a TIF_VM86 flag and do the fixups 
> in enter_from_user_mode and prepare_return_to_usermode. See the patches I just 
> sent (and tip/x88/asm, which they apply to).
> 
> 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

Hm?

Thanks,

	Ingo