Marcelo Tosatti wrote: > 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.
Not need. The information will all be contained in eflags and cr0 as returned to userspace. The bug is that the wrong information is currently returned, thus saved/restored. > >>> 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. ATM, I fighting against too many customer bugs. And you have the test case for this particular issue, I assume. So don't wait for me here. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
