On 04/08/2010 10:22 AM, Jan Kiszka wrote:
Avi Kivity wrote:
On 04/07/2010 11:24 PM, Marcelo Tosatti wrote:
During initialization, WinXP.32 switches to virtual-8086 mode, with
paging enabled, to use VGABIOS functions.
Since enter_pmode unconditionally clears IOPL and VM bits in RFLAGS
flags = vmcs_readl(GUEST_RFLAGS);
flags&= ~(X86_EFLAGS_IOPL | X86_EFLAGS_VM);
flags |= (vmx->rmode.save_iopl<< IOPL_SHIFT);
vmcs_writel(GUEST_RFLAGS, flags);
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.
The following patch fixes it, but it has some drawbacks:
- cpu_synchronize_state+writeback is noticeably slow with tpr patching,
this makes it slower.
Isn't it a very rare event?
It has to be - otherwise the decision to go for full sync and individual
get/set IOCTL would have been wrong. What happens during tpr patching?
tpr patching listens for instructions which access the tpr and patches
them to a call instruction (targeting some hacky code in the bios).
Since there are a limited number of such instructions (20-30 IIRC) you
expect tpr patching to happen very rarely.
- Its a fugly workaround.
True.
Still likely the way to go for old kernels.
It's a bugfix that can go into -stable and supported distribution kernels.
--
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
