On 04/08/2010 05:16 PM, 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.
That ioctl already exists, KVM_{GET,SET}_REGS.
We're writing via KVM_SET_SREGS eflags.vm=1 and eflags.iopl=3 while
cr0.pe=0. vmx_set_rflags() notices this and sets rmode.save_vm=1 and
rmode.save_iopl=3. Next we write via KVM_SET_SREGS cr0.pe=1. So we
call enter_pmode(), and recover eflags.vm and eflags.iopl from rmode.vm
and rmode.iopl. Win!
It's similar to how we handle cr0.ts, sometimes the host owns it so we
keep it in a shadow register, sometimes the guest owns it so we keep it
in cr0.
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.
I took it to mean he wants to kill the other qemu workarounds for kernel
bugs.
--
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
