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.
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. :)
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
