On Thu, Apr 08, 2010 at 11:05:56AM +0300, Avi Kivity wrote: > On 04/08/2010 10:54 AM, Jan Kiszka wrote: > > > >>>>Looks like KVM_SET_REGS should write rmode.save_iopl (and a new save_vm)? > >>>> > >>>Just like we manipulate the flags for guest debugging in the > >>>set/get_rflags vendor handlers, the same should happen for IOPL and VM. > >>>This is no business of enter_pmode/rmode. > >>> > >>This is vendor specific code, and it isn't manipulating guest values, > >>only host values (->set_rflags() is called when the guest value changes, > >>which isn't happening here). Of course some refactoring will be helpful > >>here. > >Actually, the bug is that enter_pmode/rmode update save_iopl (and that > >no one saves the VM bit). That should happen in vmx_set_rflags to also > >keep track of changes _while_ we are in rmode. > > Exactly - that's what I suggested above. And new ioctl to save/restore save_iopl/save_vm. > >enter_rmode/pmode should > >just trigger a set_rflags to update things. > > Not what I had in mind, but a valid implementation. > > >And vmx_get_rflags must > >properly inject the saved flags instead of masking them out. > > Yes. No one ever bothers to play with iopl in real mode, so we > never noticed this. We do this for cr0 for example. > > >>It's a bugfix that can go into -stable and supported distribution kernels. > >Well, would be happy to throw out tones of workaround based on this > >approach. :) Do you mean you'd be interested in writing the patch? Sure, go ahead, let me know otherwise. > And I'll be happy to apply such patches. Just ensure that 2.6.32.y > and above have the fixes so we don't introduce regressions (I think > most workarounds are a lot older). > > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
