Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
On Fri, 18 Apr 2008 10:25:15 -0500
Anthony Liguori [EMAIL PROTECTED] wrote:
I'd prefer you not do an emulate_instruction loop at all. Just emulate
one instruction on vmentry failure and let VT tell you what instructions
you need to emulate.
It's only four instructions so I don't think the performance is going to
matter. Take a look at the patch I posted previously.
you were right, I not updated eip correctly. It is fixed now with the
following code:
case 0xea: /* jmp (far, absolute) */ {
struct kvm_segment kvm_seg;
uint16_t eip;
uint16_t sel;
int ret;
eip = insn_fetch(u16, 2, c-eip);
sel = insn_fetch(u16, 2, c-eip);
kvm_x86_ops-get_segment(ctxt-vcpu, kvm_seg, VCPU_SREG_CS);
kvm_seg.selector = sel;
ret = load_segment_descriptor(ctxt-vcpu, kvm_seg.selector, 9,
VCPU_SREG_CS);
if (ret 0 ) {
printk(KERN_INFO %s: Failed to load CS selector\n,
__FUNCTION__);
goto cannot_emulate;
}
c-eip = eip;
break;
I print the instruction to be emulated and it seems ok. I have the following
outputs:
[24203.663324] vmentry_failure: emulation at (46e53) rip 6e13: ea 18 6e 18
[24203.664668] vmentry_failure: emulation at (46e58) rip 6e18: 66 b8 20 00
[24203.668650] vmentry_failure: emulation failed (vmentry failure) rip 6e18 66
b8 20 00
So the emulation that failed is mov $0x20, %ax. It needs to be
emulated. As you said Anthony it's only four instructions that need to
be emulated, shouldn't be a big issue.
Best regards,
Guillaume
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
Anthony Liguori wrote: I'd prefer you not do an emulate_instruction loop at all. Just emulate one instruction on vmentry failure and let VT tell you what instructions you need to emulate. It's only four instructions so I don't think the performance is going to matter. Take a look at the patch I posted previously. Once we remove the other VT realmode hacks, we may need more instructions emulated. Consider for example changing to real mode without reloading fs and gs; this will cause all real mode code to be emulated. However, there's no need to do everything at once; the loop can certainly be added later when we have a proven need for it. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
On Tue, 15 Apr 2008 16:06:43 +0300
Avi Kivity [EMAIL PROTECTED] wrote:
...
handle_vmentry_failure: invalid guest state
handle_vmentry_failure: start emulation
handle_vmentry_failure: emulation failed
What instruction failed, exactly?
I added the code do dump the instruction and it seems that it's the
emulation of 0xe6 (== out imm8, al) that failed. I made modifications
to emulate it (see below) and now I have another problem in kvm
userspace with the following message (and the emulation doesn't work):
enterprise:~ $ kvm_run: Operation not permitted
enterprise:~ $ kvm_run returned -1
You need to load rip as well.
Ooops, yes. So jump far emulation is now like:
+ case 0xea: /* jmp far */ {
+ struct kvm_segment kvm_seg;
+ long int eip;
+ int ret;
+
+ kvm_x86_ops-get_segment(ctxt-vcpu, kvm_seg, VCPU_SREG_CS);
+
+ ret = load_segment_descriptor(ctxt-vcpu, kvm_seg.selector, 9,
VCPU_SREG_CS);
+ if (ret 0){
+ printk(KERN_INFO %s: Failed to load CS descriptor\n,
__FUNCTION__);
+ goto cannot_emulate;
+ }
+
+ switch (c-op_bytes) {
+ case 2:
+ eip = insn_fetch(s16, 2, c-eip);
+ break;
+ case 4:
+ eip = insn_fetch(s32, 4, c-eip);
+ break;
+ default:
+ DPRINTF(jmp far: Invalid op_bytes\n);
+ goto cannot_emulate;
+ }
+ printk(KERN_INFO eip == 0x%lx\n, eip);
+ c-eip = eip;
+ break;
+ }
It seems that the jump to cs:eip works and now I have the following error:
[18535.446917] handle_vmentry_failure: invalid guest state
[18535.449519] handle_vmentry_failure: start emulation
[18535.457519] eip == 0x6e18
[18535.467685] handle_vmentry_failure: emulation of 0xe6 failed
For the emulation of 0xe6 I used the following one that I found in
nitin's tree:
+ case 0xe6: /* out imm8, al */
+ case 0xe7: /* out imm8, ax/eax */ {
+ struct kvm_io_device *pio_dev;
+
+ pio_dev = vcpu_find_pio_dev(ctxt-vcpu, c-src.val);
+ kvm_iodevice_write(pio_dev, c-src.val,
+ (c-d ByteOp) ? 1 : c-op_bytes,
+ c-regs[VCPU_REGS_RAX]);
+ }
+ break;
I will look closer where is the problem and as you suggested, I will
display the instruction to be emulated and the register state before
and after, and compare with the expected state.
Thanks for your help,
Regards,
Guillaume
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
On Fri, 18 Apr 2008 14:18:16 +0200 Guillaume Thouvenin [EMAIL PROTECTED] wrote: I added the code do dump the instruction and it seems that it's the emulation of 0xe6 (== out imm8, al) that failed. I made modifications to emulate it (see below) and now I have another problem in kvm userspace with the following message (and the emulation doesn't work): enterprise:~ $ kvm_run: Operation not permitted enterprise:~ $ kvm_run returned -1 Ok for this one it seems to be a wrong value in the opcode_table[]. Now it generates an oops. I'm investigating... Regards, Guillaume --- Apr 18 14:48:53 enterprise kernel: [22321.010006] handle_vmentry_failure: invalid guest state Apr 18 14:48:53 enterprise kernel: [22321.011953] handle_vmentry_failure: start emulation Apr 18 14:48:53 enterprise kernel: [22321.015875] c-op_bytes == 2 Apr 18 14:48:53 enterprise kernel: [22321.019862] eip == 0x6e18 Message from [EMAIL PROTECTED] at Fri Apr 18 14:48:54 2008 ... enterprise kernel: [22321.027850] Oops: [2] SMP Message from [EMAIL PROTECTED] at Fri Apr 18 14:48:54 2008 ... enterprise kernel: [22321.027850] Code: 75 58 48 8b 7d 00 e8 64 4f ff ff f6 85 98 00 00 00 01 ba 01 00 00 00 75 04 0f b6 55 4c 48 8b 75 58 48 8d 8d a0 00 00 00 48 89 c7 ff 50 08 e9 f1 07 00 00 8a 45 4c 3c 02 74 0a 3c 04 0f 85 73 13 Message from [EMAIL PROTECTED] at Fri Apr 18 14:48:54 2008 ... enterprise kernel: [22321.027850] CR2: 0008 Apr 18 14:48:54 enterprise kernel: [22321.027850] PGD 36f1a8067 PUD 327c17067 PMD 0 Apr 18 14:48:54 enterprise kernel: [22321.027850] CPU 1 Apr 18 14:48:54 enterprise kernel: [22321.027850] Modules linked in: kvm_intel kvm aic94xx libsas scsi_transport_sas [last unloaded: kvm] Apr 18 14:48:54 enterprise kernel: [22321.027850] Pid: 7814, comm: qemu-system-x86 Tainted: G D 2.6.25 #207 Apr 18 14:48:54 enterprise kernel: [22321.027850] RIP: 0010:[88043933] [88043933] :kvm:x86_emulate_insn+0x2d97/0x414c Apr 18 14:48:54 enterprise kernel: [22321.027850] RSP: 0018:81033005fb68 EFLAGS: 00010202 Apr 18 14:48:54 enterprise kernel: [22321.027850] RAX: RBX: 810344cf9440 RCX: 810344cf9498 Apr 18 14:48:54 enterprise kernel: [22321.027850] RDX: 0001 RSI: 007a RDI: Apr 18 14:48:54 enterprise kernel: [22321.027850] RBP: 810344cf93f8 R08: R09: Apr 18 14:48:54 enterprise kernel: [22321.027850] R10: R11: R12: Apr 18 14:48:54 enterprise kernel: [22321.027850] R13: 88051e50 R14: 810344cf9498 R15: 7ad6 Apr 18 14:48:54 enterprise kernel: [22321.027850] FS: 4108b950() GS:810397c250c0() knlGS: Apr 18 14:48:54 enterprise kernel: [22321.027850] CS: 0010 DS: 002b ES: 002b CR0: 80050033 Apr 18 14:48:54 enterprise kernel: [22321.027850] CR2: 0008 CR3: 0003301b2000 CR4: 26e0 Apr 18 14:48:54 enterprise kernel: [22321.027850] DR0: DR1: DR2: Apr 18 14:48:54 enterprise kernel: [22321.027850] DR3: DR6: 0ff0 DR7: 0400 Apr 18 14:48:54 enterprise kernel: [22321.027850] Process qemu-system-x86 (pid: 7814, threadinfo 81033005e000, task 810396023080) Apr 18 14:48:54 enterprise kernel: [22321.027850] Stack: 81033005fb04 0088 810344cf9438 810344cf9440 Apr 18 14:48:54 enterprise kernel: [22321.027850] 00040040 00055e1c 00055e1c 810344cf9498 Apr 18 14:48:54 enterprise kernel: [22321.027850] 0089 8805087a 810344cf80c0 Apr 18 14:48:54 enterprise kernel: [22321.027850] Call Trace: Apr 18 14:48:54 enterprise kernel: [22321.027850] [88038d91] ? :kvm:emulate_instruction+0x1e5/0x2b9 Apr 18 14:48:54 enterprise kernel: [22321.027850] [88057cd1] ? :kvm_intel:kvm_handle_exit+0xea/0x1e8 Apr 18 14:48:54 enterprise kernel: [22321.027850] [88057a96] ? :kvm_intel:vmx_intr_assist+0x68/0x1b9 Apr 18 14:48:54 enterprise kernel: [22321.027850] [80563398] ? __down_read+0x12/0xa1 Apr 18 14:48:54 enterprise kernel: [22321.027850] [8803b940] ? :kvm:kvm_arch_vcpu_ioctl_run+0x4ae/0x631 Apr 18 14:48:54 enterprise kernel: [22321.027850] [80291ec9] ? touch_atime+0xae/0xed Apr 18 14:48:54 enterprise kernel: [22321.027850] [8803672e] ? :kvm:kvm_vcpu_ioctl+0xf3/0x3a1 Apr 18 14:48:54 enterprise kernel: [22321.027850] [802802c0] ? do_sync_read+0xd1/0x118 Apr 18 14:48:54 enterprise kernel: [22321.027850] [880363b1] ? :kvm:kvm_vm_ioctl+0x1ab/0x1c3 Apr 18 14:48:54 enterprise kernel: [22321.027850] [8028ae49] ? vfs_ioctl+0x21/0x6b Apr 18 14:48:54 enterprise kernel: [22321.027850] [8028b0e6] ? do_vfs_ioctl+0x253/0x264 Apr 18 14:48:54 enterprise kernel: [22321.027850]
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
Guillaume Thouvenin wrote:
On Tue, 15 Apr 2008 16:06:43 +0300
Avi Kivity [EMAIL PROTECTED] wrote:
...
handle_vmentry_failure: invalid guest state
handle_vmentry_failure: start emulation
handle_vmentry_failure: emulation failed
What instruction failed, exactly?
I added the code do dump the instruction and it seems that it's the
emulation of 0xe6 (== out imm8, al) that failed. I made modifications
to emulate it (see below) and now I have another problem in kvm
userspace with the following message (and the emulation doesn't work):
enterprise:~ $ kvm_run: Operation not permitted
enterprise:~ $ kvm_run returned -1
You need to load rip as well.
Ooops, yes. So jump far emulation is now like:
+ case 0xea: /* jmp far */ {
+ struct kvm_segment kvm_seg;
+ long int eip;
+ int ret;
+
+ kvm_x86_ops-get_segment(ctxt-vcpu, kvm_seg, VCPU_SREG_CS);
+
+ ret = load_segment_descriptor(ctxt-vcpu, kvm_seg.selector,
9, VCPU_SREG_CS);
+ if (ret 0){
+ printk(KERN_INFO %s: Failed to load CS
descriptor\n, __FUNCTION__);
+ goto cannot_emulate;
+ }
+
+ switch (c-op_bytes) {
+ case 2:
+ eip = insn_fetch(s16, 2, c-eip);
+ break;
+ case 4:
+ eip = insn_fetch(s32, 4, c-eip);
+ break;
+ default:
+ DPRINTF(jmp far: Invalid op_bytes\n);
+ goto cannot_emulate;
+ }
+ printk(KERN_INFO eip == 0x%lx\n, eip);
+ c-eip = eip;
+ break;
+ }
It seems that the jump to cs:eip works and now I have the following error:
[18535.446917] handle_vmentry_failure: invalid guest state
[18535.449519] handle_vmentry_failure: start emulation
[18535.457519] eip == 0x6e18
[18535.467685] handle_vmentry_failure: emulation of 0xe6 failed
For the emulation of 0xe6 I used the following one that I found in
nitin's tree:
This doesn't seem right. You should have been able to break out of the
emulator long before encountering an out instruction. The next
instruction you encounter should be a mov instruction. Are you sure
you're updating eip correctly?
Regards,
Anthony Liguori
+ case 0xe6: /* out imm8, al */
+ case 0xe7: /* out imm8, ax/eax */ {
+ struct kvm_io_device *pio_dev;
+
+ pio_dev = vcpu_find_pio_dev(ctxt-vcpu, c-src.val);
+ kvm_iodevice_write(pio_dev, c-src.val,
+ (c-d ByteOp) ? 1 : c-op_bytes,
+ c-regs[VCPU_REGS_RAX]);
+ }
+ break;
I will look closer where is the problem and as you suggested, I will
display the instruction to be emulated and the register state before
and after, and compare with the expected state.
Thanks for your help,
Regards,
Guillaume
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
On Fri, 18 Apr 2008 08:23:07 -0500
Anthony Liguori [EMAIL PROTECTED] wrote:
This doesn't seem right. You should have been able to break out of the
emulator long before encountering an out instruction. The next
instruction you encounter should be a mov instruction. Are you sure
you're updating eip correctly?
I think that eip is updated correctly but you're right, I think that
the condition to stop emulation is not well implemented. I emulate a
lot of mov instructions and I remain blocked in the emulation loop
until I reach the out instruction. The loop is the following:
[...]
cs_rpl = vmcs_read16(GUEST_CS_SELECTOR) SELECTOR_RPL_MASK;
ss_rpl = vmcs_read16(GUEST_SS_SELECTOR) SELECTOR_RPL_MASK;
while (cs_rpl != ss_rpl) {
if (emulate_instruction(vcpu, NULL, 0,0, 0) == EMULATE_FAIL) {
printk(KERN_INFO %s: emulation of 0x%x failed\n,
__FUNCTION__,
vcpu-arch.emulate_ctxt.decode.b);
return -1;
}
cs_rpl = vmcs_read16(GUEST_CS_SELECTOR) SELECTOR_RPL_MASK;
ss_rpl = vmcs_read16(GUEST_SS_SELECTOR) SELECTOR_RPL_MASK;
}
printk(KERN_INFO %s: VMX friendly state recovered\n, __FUNCTION__);
// I never reach this point
Maybe CS and SS selector are not well updated. I will add trace to see
their values before and after the emulation.
Regards,
Guillaume
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
Guillaume Thouvenin wrote:
On Fri, 18 Apr 2008 08:23:07 -0500
Anthony Liguori [EMAIL PROTECTED] wrote:
This doesn't seem right. You should have been able to break out of the
emulator long before encountering an out instruction. The next
instruction you encounter should be a mov instruction. Are you sure
you're updating eip correctly?
I think that eip is updated correctly but you're right, I think that
the condition to stop emulation is not well implemented. I emulate a
lot of mov instructions and I remain blocked in the emulation loop
until I reach the out instruction. The loop is the following:
[...]
cs_rpl = vmcs_read16(GUEST_CS_SELECTOR) SELECTOR_RPL_MASK;
ss_rpl = vmcs_read16(GUEST_SS_SELECTOR) SELECTOR_RPL_MASK;
while (cs_rpl != ss_rpl) {
if (emulate_instruction(vcpu, NULL, 0,0, 0) == EMULATE_FAIL) {
printk(KERN_INFO %s: emulation of 0x%x failed\n,
__FUNCTION__,
vcpu-arch.emulate_ctxt.decode.b);
return -1;
}
cs_rpl = vmcs_read16(GUEST_CS_SELECTOR) SELECTOR_RPL_MASK;
ss_rpl = vmcs_read16(GUEST_SS_SELECTOR) SELECTOR_RPL_MASK;
}
printk(KERN_INFO %s: VMX friendly state recovered\n, __FUNCTION__);
// I never reach this point
Maybe CS and SS selector are not well updated. I will add trace to see
their values before and after the emulation.
I'd prefer you not do an emulate_instruction loop at all. Just emulate
one instruction on vmentry failure and let VT tell you what instructions
you need to emulate.
It's only four instructions so I don't think the performance is going to
matter. Take a look at the patch I posted previously.
Regards,
Anthony Liguori
Regards,
Guillaume
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
On Mon, 07 Apr 2008 11:05:06 -0500
Anthony Liguori [EMAIL PROTECTED] wrote:
Perhaps a viable way to fix this upstream would be to catch the vmentry
failure, look to see if SS.CPL != CS.CPL, and if so, invoke
x86_emulate() in a loop until SS.CPL == CS.CPL.
There are very few instructions in gfxboot that would need to be added
to x86_emulate (if they aren't already there).
So to see if I'm on the good way here is an attempt to implement the
solution. It doesn't work yet.
I'm trying to:
- Disable the code that modifies SS value in order to detect VM entry
failure
- Add the handler that catches the VM entry failure
- Emulate the instruction until we recover a friendly VMX state
= add the jmp far (opcode 0xea) instruction in the emulation.
With the patch, the VM entry failure is caught but the jmp far
instruction seems to fail. I've got the following dmesg:
...
handle_vmentry_failure: invalid guest state
handle_vmentry_failure: start emulation
handle_vmentry_failure: emulation failed
...
Regards,
Guillaume
---
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 8e5d664..a56bd83 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1178,13 +1178,16 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
update_exception_bitmap(vcpu);
+ fix_pmode_dataseg(VCPU_SREG_SS, vcpu-arch.rmode.ss);
fix_pmode_dataseg(VCPU_SREG_ES, vcpu-arch.rmode.es);
fix_pmode_dataseg(VCPU_SREG_DS, vcpu-arch.rmode.ds);
fix_pmode_dataseg(VCPU_SREG_GS, vcpu-arch.rmode.gs);
fix_pmode_dataseg(VCPU_SREG_FS, vcpu-arch.rmode.fs);
+#if 0
vmcs_write16(GUEST_SS_SELECTOR, 0);
vmcs_write32(GUEST_SS_AR_BYTES, 0x93);
+#endif
vmcs_write16(GUEST_CS_SELECTOR,
vmcs_read16(GUEST_CS_SELECTOR) ~SELECTOR_RPL_MASK);
@@ -1952,6 +1955,33 @@ static int handle_rmode_exception(struct kvm_vcpu *vcpu,
return 0;
}
+static int handle_vmentry_failure(u32 exit_reason, struct kvm_vcpu *vcpu)
+{
+ unsigned int basic_exit_reason = (uint16_t) exit_reason;
+ unsigned int cs_rpl = vmcs_read16(GUEST_CS_SELECTOR)
SELECTOR_RPL_MASK;
+ unsigned int ss_rpl = vmcs_read16(GUEST_SS_SELECTOR)
SELECTOR_RPL_MASK;
+
+ switch (basic_exit_reason) {
+ case EXIT_REASON_INVALID_GUEST_STATE:
+ printk(KERN_INFO %s: invalid guest state\n,
__FUNCTION__);
+ printk(KERN_INFO %s: start emulation \n,
__FUNCTION__);
+ while (cs_rpl != ss_rpl) {
+ if (emulate_instruction(vcpu, NULL, 0, 0, 0) ==
EMULATE_FAIL) {
+ printk(KERN_INFO %s: emulation
failed\n, __FUNCTION__);
+ return 0;
+ }
+ cs_rpl = vmcs_read16(GUEST_CS_SELECTOR)
SELECTOR_RPL_MASK;
+ ss_rpl = vmcs_read16(GUEST_SS_SELECTOR)
SELECTOR_RPL_MASK;
+ }
+ printk(KERN_INFO %s: VMX friendly state recovered\n,
__FUNCTION__);
+ break;
+ default:
+ printk(KERN_INFO VM-entry failure due to unkown
reason\n);
+ return 0;
+ }
+ return 1;
+}
+
static int handle_exception(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -2364,6 +2394,9 @@ static int kvm_handle_exit(struct kvm_run *kvm_run,
struct kvm_vcpu *vcpu)
KVMTRACE_3D(VMEXIT, vcpu, exit_reason, (u32)vmcs_readl(GUEST_RIP),
(u32)((u64)vmcs_readl(GUEST_RIP) 32), entryexit);
+ if (unlikely(exit_reason VMX_EXIT_REASONS_FAILED_VMENTRY))
+ return handle_vmentry_failure(exit_reason, vcpu);
+
if (unlikely(vmx-fail)) {
kvm_run-exit_reason = KVM_EXIT_FAIL_ENTRY;
kvm_run-fail_entry.hardware_entry_failure_reason
diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h
index 5dff460..200c0f8 100644
--- a/arch/x86/kvm/vmx.h
+++ b/arch/x86/kvm/vmx.h
@@ -223,7 +223,10 @@ enum vmcs_field {
#define EXIT_REASON_IO_INSTRUCTION 30
#define EXIT_REASON_MSR_READ31
#define EXIT_REASON_MSR_WRITE 32
+#define EXIT_REASON_INVALID_GUEST_STATE 33
+#define EXIT_REASON_MSR_LOADING 34
#define EXIT_REASON_MWAIT_INSTRUCTION 36
+#define EXIT_REASON_MACHINE_CHECK 41
#define EXIT_REASON_TPR_BELOW_THRESHOLD 43
#define EXIT_REASON_APIC_ACCESS 44
#define EXIT_REASON_WBINVD 54
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0ce5563..b38065d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3267,7 +3267,7 @@ static int load_segment_descriptor_to_kvm_desct(struct
kvm_vcpu *vcpu,
return 0;
}
-static int load_segment_descriptor(struct kvm_vcpu *vcpu, u16 selector,
+int load_segment_descriptor(struct kvm_vcpu *vcpu, u16
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
Guillaume Thouvenin wrote:
On Mon, 07 Apr 2008 11:05:06 -0500
Anthony Liguori [EMAIL PROTECTED] wrote:
Perhaps a viable way to fix this upstream would be to catch the vmentry
failure, look to see if SS.CPL != CS.CPL, and if so, invoke
x86_emulate() in a loop until SS.CPL == CS.CPL.
There are very few instructions in gfxboot that would need to be added
to x86_emulate (if they aren't already there).
So to see if I'm on the good way here is an attempt to implement the
solution. It doesn't work yet.
I'm trying to:
- Disable the code that modifies SS value in order to detect VM entry
failure
- Add the handler that catches the VM entry failure
- Emulate the instruction until we recover a friendly VMX state
= add the jmp far (opcode 0xea) instruction in the emulation.
With the patch, the VM entry failure is caught but the jmp far
instruction seems to fail. I've got the following dmesg:
...
handle_vmentry_failure: invalid guest state
handle_vmentry_failure: start emulation
handle_vmentry_failure: emulation failed
What instruction failed, exactly?
...
Regards,
Guillaume
---
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 8e5d664..a56bd83 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1178,13 +1178,16 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
update_exception_bitmap(vcpu);
+ fix_pmode_dataseg(VCPU_SREG_SS, vcpu-arch.rmode.ss);
fix_pmode_dataseg(VCPU_SREG_ES, vcpu-arch.rmode.es);
fix_pmode_dataseg(VCPU_SREG_DS, vcpu-arch.rmode.ds);
fix_pmode_dataseg(VCPU_SREG_GS, vcpu-arch.rmode.gs);
fix_pmode_dataseg(VCPU_SREG_FS, vcpu-arch.rmode.fs);
You need to drop the fixes rather than add more.
+#if 0
vmcs_write16(GUEST_SS_SELECTOR, 0);
vmcs_write32(GUEST_SS_AR_BYTES, 0x93);
+#endif
vmcs_write16(GUEST_CS_SELECTOR,
vmcs_read16(GUEST_CS_SELECTOR) ~SELECTOR_RPL_MASK);
@@ -1952,6 +1955,33 @@ static int handle_rmode_exception(struct kvm_vcpu
*vcpu,
return 0;
}
+static int handle_vmentry_failure(u32 exit_reason, struct kvm_vcpu *vcpu)
+{
+ unsigned int basic_exit_reason = (uint16_t) exit_reason;
+ unsigned int cs_rpl = vmcs_read16(GUEST_CS_SELECTOR)
SELECTOR_RPL_MASK;
+ unsigned int ss_rpl = vmcs_read16(GUEST_SS_SELECTOR)
SELECTOR_RPL_MASK;
+
+ switch (basic_exit_reason) {
+ case EXIT_REASON_INVALID_GUEST_STATE:
+ printk(KERN_INFO %s: invalid guest state\n,
__FUNCTION__);
+ printk(KERN_INFO %s: start emulation \n,
__FUNCTION__);
+ while (cs_rpl != ss_rpl) {
+ if (emulate_instruction(vcpu, NULL, 0, 0, 0) ==
EMULATE_FAIL) {
+ printk(KERN_INFO %s: emulation
failed\n, __FUNCTION__);
+ return 0;
+ }
+ cs_rpl = vmcs_read16(GUEST_CS_SELECTOR)
SELECTOR_RPL_MASK;
+ ss_rpl = vmcs_read16(GUEST_SS_SELECTOR)
SELECTOR_RPL_MASK;
+ }
+ printk(KERN_INFO %s: VMX friendly state recovered\n,
__FUNCTION__);
+ break;
+ default:
+ printk(KERN_INFO VM-entry failure due to unkown
reason\n);
+ return 0;
+ }
+ return 1;
+}
+
static int handle_exception(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -2364,6 +2394,9 @@ static int kvm_handle_exit(struct kvm_run *kvm_run,
struct kvm_vcpu *vcpu)
KVMTRACE_3D(VMEXIT, vcpu, exit_reason, (u32)vmcs_readl(GUEST_RIP),
(u32)((u64)vmcs_readl(GUEST_RIP) 32), entryexit);
+ if (unlikely(exit_reason VMX_EXIT_REASONS_FAILED_VMENTRY))
+ return handle_vmentry_failure(exit_reason, vcpu);
+
if (unlikely(vmx-fail)) {
kvm_run-exit_reason = KVM_EXIT_FAIL_ENTRY;
kvm_run-fail_entry.hardware_entry_failure_reason
diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h
index 5dff460..200c0f8 100644
--- a/arch/x86/kvm/vmx.h
+++ b/arch/x86/kvm/vmx.h
@@ -223,7 +223,10 @@ enum vmcs_field {
#define EXIT_REASON_IO_INSTRUCTION 30
#define EXIT_REASON_MSR_READ31
#define EXIT_REASON_MSR_WRITE 32
+#define EXIT_REASON_INVALID_GUEST_STATE 33
+#define EXIT_REASON_MSR_LOADING 34
#define EXIT_REASON_MWAIT_INSTRUCTION 36
+#define EXIT_REASON_MACHINE_CHECK 41
#define EXIT_REASON_TPR_BELOW_THRESHOLD 43
#define EXIT_REASON_APIC_ACCESS 44
#define EXIT_REASON_WBINVD 54
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0ce5563..b38065d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3267,7 +3267,7 @@ static int load_segment_descriptor_to_kvm_desct(struct
kvm_vcpu
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
On Mon, 07 Apr 2008 11:05:06 -0500 Anthony Liguori [EMAIL PROTECTED] wrote: Perhaps a viable way to fix this upstream would be to catch the vmentry failure, look to see if SS.CPL != CS.CPL, and if so, invoke x86_emulate() in a loop until SS.CPL == CS.CPL. I tried this solution some time ago but unfortunately x86_emulate() failed. I suspected a problem with guest EIP that could different between the vmentry catch and the emulation. I will rebase my patch and post them on the mailing list. Regards, Guillaume - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
Guillaume Thouvenin wrote: On Mon, 07 Apr 2008 11:05:06 -0500 Anthony Liguori [EMAIL PROTECTED] wrote: Perhaps a viable way to fix this upstream would be to catch the vmentry failure, look to see if SS.CPL != CS.CPL, and if so, invoke x86_emulate() in a loop until SS.CPL == CS.CPL. I tried this solution some time ago but unfortunately x86_emulate() failed. I suspected a problem with guest EIP that could different between the vmentry catch and the emulation. I will rebase my patch and post them on the mailing list. x86 emulate is missing support for jmp far which is used to switch into protected mode. It just needs to be added. Regards, Anthony Liguori Regards, Guillaume - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
On Tue, 08 Apr 2008 07:14:13 -0500 Anthony Liguori [EMAIL PROTECTED] wrote: Guillaume Thouvenin wrote: On Mon, 07 Apr 2008 11:05:06 -0500 Anthony Liguori [EMAIL PROTECTED] wrote: Perhaps a viable way to fix this upstream would be to catch the vmentry failure, look to see if SS.CPL != CS.CPL, and if so, invoke x86_emulate() in a loop until SS.CPL == CS.CPL. I tried this solution some time ago but unfortunately x86_emulate() failed. I suspected a problem with guest EIP that could different between the vmentry catch and the emulation. I will rebase my patch and post them on the mailing list. x86 emulate is missing support for jmp far which is used to switch into protected mode. It just needs to be added. Ok I see. I understand now why you said in a previous email that KVM needs to have a proper load_seg() function like the Xen's x86_emulate. This function is used to load the segment in a far jmp. I will look how it is done in Xen and I will try to copy the stuff like you did. Regards, Guillaume - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
Guillaume Thouvenin wrote: x86 emulate is missing support for jmp far which is used to switch into protected mode. It just needs to be added. Ok I see. I understand now why you said in a previous email that KVM needs to have a proper load_seg() function like the Xen's x86_emulate. This function is used to load the segment in a far jmp. I will look how it is done in Xen and I will try to copy the stuff like you did. kvm now has a load_segment_descriptor() function which might help. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
Alexander Graf wrote: Hi, this is an improved version of the patch I sent several weeks ago to this list. Functionally nothing changed; it still hacks into gfxboot and patches it to work on Intel CPUs on the fly. The big difference is that this version is cleaned up and should work with every future CPU available. Please do _not_ apply this patch. I send it to the list only for interested people, who would like to have a working version of KVM for their systems right now. It is neither a proper fix nor the right approach to deal with this issue. It is merely a hack that works for me and maybe for others too. Perhaps a viable way to fix this upstream would be to catch the vmentry failure, look to see if SS.CPL != CS.CPL, and if so, invoke x86_emulate() in a loop until SS.CPL == CS.CPL. There are very few instructions in gfxboot that would need to be added to x86_emulate (if they aren't already there). Regards, Anthony Liguori Alex - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
On Apr 7, 2008, at 6:05 PM, Anthony Liguori wrote: Alexander Graf wrote: Hi, this is an improved version of the patch I sent several weeks ago to this list. Functionally nothing changed; it still hacks into gfxboot and patches it to work on Intel CPUs on the fly. The big difference is that this version is cleaned up and should work with every future CPU available. Please do _not_ apply this patch. I send it to the list only for interested people, who would like to have a working version of KVM for their systems right now. It is neither a proper fix nor the right approach to deal with this issue. It is merely a hack that works for me and maybe for others too. Perhaps a viable way to fix this upstream would be to catch the vmentry failure, look to see if SS.CPL != CS.CPL, and if so, invoke x86_emulate() in a loop until SS.CPL == CS.CPL. There are very few instructions in gfxboot that would need to be added to x86_emulate (if they aren't already there). In a previous thread Avi already explained a quite reasonable way to approach this problem, which I believe is a really good approach. He wanted to x86_emulate until the environment is VMX friendly again, thus resolving big real mode problems as well. I personally agree that the real approach is way superior to my patch. I just won't have the time to do it in the near future and not being able to boot intuitively hurts KVM users unnecessarily ;-). Regards, Alex - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
Alexander Graf wrote: On Apr 7, 2008, at 6:05 PM, Anthony Liguori wrote: Alexander Graf wrote: Hi, this is an improved version of the patch I sent several weeks ago to this list. Functionally nothing changed; it still hacks into gfxboot and patches it to work on Intel CPUs on the fly. The big difference is that this version is cleaned up and should work with every future CPU available. Please do _not_ apply this patch. I send it to the list only for interested people, who would like to have a working version of KVM for their systems right now. It is neither a proper fix nor the right approach to deal with this issue. It is merely a hack that works for me and maybe for others too. Perhaps a viable way to fix this upstream would be to catch the vmentry failure, look to see if SS.CPL != CS.CPL, and if so, invoke x86_emulate() in a loop until SS.CPL == CS.CPL. There are very few instructions in gfxboot that would need to be added to x86_emulate (if they aren't already there). In a previous thread Avi already explained a quite reasonable way to approach this problem, which I believe is a really good approach. He wanted to x86_emulate until the environment is VMX friendly again, thus resolving big real mode problems as well. I've got a slightly lamer approach than what Avi probably wants. I lost interest in updating x86_emulate once I realized how far xen's copy has gotten. To get GFXBOOT 3.3.28 working just requires adding far jmp to x86_emulate. The sequence should look like: jmp pm_seg.prog_c32:switch_to_pm_20 switch_to_pm_20: bits 32 mov ax,pm_seg.prog_d16 mov ds,ax mov eax,ss Which means we'll get 3 vmentry failures. The two moves should already be supported by x86_emulate but I haven't confirmed. It's not a complete solution to our real mode woes but I think it's a reasonable first step. Regards, Anthony Liguori I personally agree that the real approach is way superior to my patch. I just won't have the time to do it in the near future and not being able to boot intuitively hurts KVM users unnecessarily ;-). Regards, Alex x86_emulate.patch Description: application/mbox - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
On Apr 7, 2008, at 6:51 PM, Anthony Liguori wrote: Alexander Graf wrote: On Apr 7, 2008, at 6:05 PM, Anthony Liguori wrote: Alexander Graf wrote: Hi, this is an improved version of the patch I sent several weeks ago to this list. Functionally nothing changed; it still hacks into gfxboot and patches it to work on Intel CPUs on the fly. The big difference is that this version is cleaned up and should work with every future CPU available. Please do _not_ apply this patch. I send it to the list only for interested people, who would like to have a working version of KVM for their systems right now. It is neither a proper fix nor the right approach to deal with this issue. It is merely a hack that works for me and maybe for others too. Perhaps a viable way to fix this upstream would be to catch the vmentry failure, look to see if SS.CPL != CS.CPL, and if so, invoke x86_emulate() in a loop until SS.CPL == CS.CPL. There are very few instructions in gfxboot that would need to be added to x86_emulate (if they aren't already there). In a previous thread Avi already explained a quite reasonable way to approach this problem, which I believe is a really good approach. He wanted to x86_emulate until the environment is VMX friendly again, thus resolving big real mode problems as well. I've got a slightly lamer approach than what Avi probably wants. I lost interest in updating x86_emulate once I realized how far xen's copy has gotten. To get GFXBOOT 3.3.28 working just requires adding far jmp to x86_emulate. The sequence should look like: jmp pm_seg.prog_c32:switch_to_pm_20 switch_to_pm_20: bits 32 mov ax,pm_seg.prog_d16 mov ds,ax mov eax,ss Which means we'll get 3 vmentry failures. The two moves should already be supported by x86_emulate but I haven't confirmed. It's not a complete solution to our real mode woes but I think it's a reasonable first step. Right, this was exactly the approach I wanted to go at first. I just backed off it as I saw how much ljmp actually does, as normal x86 CPUs switch to PM not on cr0 setting, but on the ljmp after that. So is that simple implementation you have written actually doing the right thing? Regards, Alex Regards, Anthony Liguori I personally agree that the real approach is way superior to my patch. I just won't have the time to do it in the near future and not being able to boot intuitively hurts KVM users unnecessarily ;-). Regards, Alex x86_emulate.patch - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
Alexander Graf wrote: On Apr 7, 2008, at 6:51 PM, Anthony Liguori wrote: Alexander Graf wrote: On Apr 7, 2008, at 6:05 PM, Anthony Liguori wrote: Alexander Graf wrote: Hi, this is an improved version of the patch I sent several weeks ago to this list. Functionally nothing changed; it still hacks into gfxboot and patches it to work on Intel CPUs on the fly. The big difference is that this version is cleaned up and should work with every future CPU available. Please do _not_ apply this patch. I send it to the list only for interested people, who would like to have a working version of KVM for their systems right now. It is neither a proper fix nor the right approach to deal with this issue. It is merely a hack that works for me and maybe for others too. Perhaps a viable way to fix this upstream would be to catch the vmentry failure, look to see if SS.CPL != CS.CPL, and if so, invoke x86_emulate() in a loop until SS.CPL == CS.CPL. There are very few instructions in gfxboot that would need to be added to x86_emulate (if they aren't already there). In a previous thread Avi already explained a quite reasonable way to approach this problem, which I believe is a really good approach. He wanted to x86_emulate until the environment is VMX friendly again, thus resolving big real mode problems as well. I've got a slightly lamer approach than what Avi probably wants. I lost interest in updating x86_emulate once I realized how far xen's copy has gotten. To get GFXBOOT 3.3.28 working just requires adding far jmp to x86_emulate. The sequence should look like: jmp pm_seg.prog_c32:switch_to_pm_20 switch_to_pm_20: bits 32 mov ax,pm_seg.prog_d16 mov ds,ax mov eax,ss Which means we'll get 3 vmentry failures. The two moves should already be supported by x86_emulate but I haven't confirmed. It's not a complete solution to our real mode woes but I think it's a reasonable first step. Right, this was exactly the approach I wanted to go at first. I just backed off it as I saw how much ljmp actually does, as normal x86 CPUs switch to PM not on cr0 setting, but on the ljmp after that. So is that simple implementation you have written actually doing the right thing? Yes, but it won't compile as KVM does not have a proper load_seg() function like the Xen's x86_emulate. I started copying stuff in but ran against some additional ops (like -read_segment). I don't think it will be very hard to implement but it exceeded the 45 seconds I was willing to spend looking at it :-) Regards, Anthony Liguori Regards, Alex Regards, Anthony Liguori I personally agree that the real approach is way superior to my patch. I just won't have the time to do it in the near future and not being able to boot intuitively hurts KVM users unnecessarily ;-). Regards, Alex x86_emulate.patch - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] gfxboot VMX workaround v2
Anthony Liguori wrote: Yes, but it won't compile as KVM does not have a proper load_seg() function like the Xen's x86_emulate. Izik added something for task switching (see load_segment_descriptor). -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
