Re: [kvm-devel] Protected mode transitions and big real mode... still an issue
On Thu, 15 May 2008 10:33:38 +0300
Avi Kivity [EMAIL PROTECTED] wrote:
Marcelo Tosatti wrote:
1) add is storing the result in the wrong register
6486: 66 64 89 3e 72 01 mov%edi,%fs:0x172
648c: 66 be 8d 03 00 00 mov$0x38d,%esi
6492: 66 c1 e6 04 shl$0x4,%esi
6496: 66 b8 98 0a 00 00 mov$0xa98,%eax
649c: 66 03 f0add%eax,%esi
The destination for the add is %esi, but the emulation stores the
result in eax, because:
if ((c-d ModRM) c-modrm_mod == 3) {
u8 reg;
c-dst.bytes = (c-d ByteOp) ? 1 : c-op_bytes;
c-dst.ptr = decode_register(c-modrm_rm, c-regs,
c-d ByteOp);
}
modrm_reg contains 6, which is the correct register index, but
modrm_rm contains 0, so the result is stored in eax (see hack).
What version are you looking at? Current code doesn't have exactly this.
It's in my patch. I added this because in gfxboot code there is an
instruction add %eax, %esp that needs to be emulated and with the
normal path, if I remember well, we have c-dst.bytes == 0 and thus,
the emulate_2op_SrcV() function just do nothing.
Regards,
Guillaume
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Protected mode transitions and big real mode... still an issue
On Tue, 6 May 2008 20:05:39 +0300
Mohammed Gamal [EMAIL PROTECTED] wrote:
WinXP fails with the patch applied too. Ubuntu 7.10 live CD and
FreeDOS don't boot but complain about instruction mov 0x11,sreg not
being emulated.
Mohammed, can you try the patch at the end of this mail? Here it's
working with FreeDOS now (I added the emulation of 0x90 that is an xchg
instruction). I can also boot winXP Professional X64 edition. I still
have a weird issue with Ubuntu 7.10 that crashes sometimes with the
error:
kvm_run: failed entry, reason 5
kvm_run returned -8
It's a little bit strange because this error appears very often with
the wmii window manager but never with XFCE. And with wmii, it only
occurs when I move the mouse above the Qemu/KVM window. If I wait 30s
until the automatic boot it works...
So to give a summary, on my box:
OpensSuse 10.3 - OK
WinXP Pro X64 - OK
FreeDOS- OK
Ubuntu 7.10- NOK
Regards,
Guillaume
---
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e94a8c3..efde223 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1287,7 +1287,9 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
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);
+#endif
vmcs_write32(GUEST_SS_AR_BYTES, 0x93);
vmcs_write16(GUEST_CS_SELECTOR,
@@ -2648,6 +2650,73 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
return 1;
}
+static int invalid_guest_state(struct kvm_vcpu *vcpu,
+ struct kvm_run *kvm_run, u32 failure_reason)
+{
+ u16 ss, cs;
+ u8 opcodes[4];
+ unsigned long rip = vcpu-arch.rip;
+ unsigned long rip_linear;
+
+ ss = vmcs_read16(GUEST_SS_SELECTOR);
+ cs = vmcs_read16(GUEST_CS_SELECTOR);
+
+ if ((ss 0x03) != (cs 0x03)) {
+ int err;
+ rip_linear = rip + vmx_get_segment_base(vcpu, VCPU_SREG_CS);
+ emulator_read_std(rip_linear, (void *)opcodes, 4, vcpu);
+#if 0
+ printk(KERN_INFO emulation at (%lx) rip %lx: %02x %02x %02x
%02x\n,
+ rip_linear,
+ rip, opcodes[0], opcodes[1], opcodes[2],
opcodes[3]);
+#endif
+ err = emulate_instruction(vcpu, kvm_run, 0, 0, 0);
+ switch (err) {
+ case EMULATE_DONE:
+#if 0
+ printk(KERN_INFO successfully emulated
instruction\n);
+#endif
+ return 1;
+ case EMULATE_DO_MMIO:
+ printk(KERN_INFO mmio?\n);
+ return 0;
+ default:
+ kvm_report_emulation_failure(vcpu, vmentry
failure);
+ break;
+ }
+ }
+
+ kvm_run-exit_reason = KVM_EXIT_UNKNOWN;
+ kvm_run-hw.hardware_exit_reason = failure_reason;
+ return 0;
+}
+
+static int handle_vmentry_failure(struct kvm_vcpu *vcpu,
+ struct kvm_run *kvm_run,
+ u32 failure_reason)
+{
+ unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
+#if 0
+ printk(KERN_INFO Failed vm entry (exit reason 0x%x) , failure_reason);
+#endif
+ switch (failure_reason) {
+ case EXIT_REASON_INVALID_GUEST_STATE:
+#if 0
+ printk(invalid guest state \n);
+#endif
+ return invalid_guest_state(vcpu, kvm_run,
failure_reason);
+ case EXIT_REASON_MSR_LOADING:
+ printk(caused by MSR entry %ld loading.\n,
exit_qualification);
+ break;
+ case EXIT_REASON_MACHINE_CHECK:
+ printk(caused by machine check.\n);
+ break;
+ default:
+ printk(reason not known yet!\n);
+ break;
+ }
+ return 0;
+}
/*
* The exit handlers return 1 if the exit was handled fully and guest execution
* may resume. Otherwise they set the kvm_run parameter to indicate what needs
@@ -2709,6 +2778,12 @@ static int kvm_handle_exit(struct kvm_run *kvm_run,
struct kvm_vcpu *vcpu)
exit_reason != EXIT_REASON_EPT_VIOLATION))
printk(KERN_WARNING %s: unexpected, valid vectoring info and
exit reason is 0x%x\n, __func__, exit_reason);
+
+ if ((exit_reason VMX_EXIT_REASONS_FAILED_VMENTRY)) {
+ exit_reason = ~VMX_EXIT_REASONS_FAILED_VMENTRY;
+ return handle_vmentry_failure(vcpu, kvm_run, exit_reason);
+ }
+
if (exit_reason kvm_vmx_max_exit_handlers
kvm_vmx_exit_handlers[exit_reason])
return kvm_vmx_exit_handlers[exit_reason](vcpu,
Re: [kvm-devel] [ kvm-Bugs-1958715 ] kvm-userspace failed to start linux kernel (kernel panic)
On Tue, 06 May 2008 06:13:18 -0700 SourceForge.net [EMAIL PROTECTED] wrote: When I use the commit bae043c (kvm-userspace) I can start the liveCD but the next commit c33833a produces a kernel panic. I see the screen with different choice of installation but when I choose to install linux I get a kernel panic (see file attach). I insert the report of the kernel panic: --- [EMAIL PROTECTED]/local/kvm-userspace.git/bin]$ ./qemu-system-x86_64 -cdrom /images_iso/ubuntu-8.04-desktop-i386.iso -boot d -m 256 -serial stdio kvm_set_lapic: Bad file descriptor [0.00] Linux version 2.6.24-16-generic ([EMAIL PROTECTED]) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Thu Apr 10 13:23:42 UTC 2008 (Ubuntu 2.6.24-16.30-generic) [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e8000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 0fff (usable) [0.00] BIOS-e820: 0fff - 1000 (ACPI data) [0.00] BIOS-e820: fffbd000 - 0001 (reserved) [0.00] 0MB HIGHMEM available. [0.00] 255MB LOWMEM available. [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] Normal 4096 -65520 [0.00] HighMem 65520 -65520 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 -65520 [0.00] DMI 2.4 present. [0.00] ACPI: RSDP signature @ 0xC00FB450 checksum 0 [0.00] ACPI: RSDP 000FB450, 0014 (r0 QEMU ) [0.00] ACPI: RSDT 0FFF, 002C (r1 QEMU QEMURSDT1 QEMU 1) [0.00] ACPI: FACP 0FFF002C, 0074 (r1 QEMU QEMUFACP1 QEMU 1) [0.00] ACPI: DSDT 0FFF0100, 2464 (r1 BXPC BXDSDT1 INTL 20061109) [0.00] ACPI: FACS 0FFF00C0, 0040 [0.00] ACPI: APIC 0FFF2568, 00E0 (r1 QEMU QEMUAPIC1 QEMU 1) [0.00] ACPI: PM-Timer IO Port: 0xb008 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 6:2 APIC version 20 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled) [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled) [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] disabled) [0.00] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] disabled) [0.00] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] disabled) [0.00] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled) [0.00] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] disabled) [0.00] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x09] disabled) [0.00] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] disabled) [0.00] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0b] disabled) [0.00] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0c] disabled) [0.00] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0d] disabled) [0.00] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0e] disabled) [0.00] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0f] disabled) [0.00] ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 1, version 17, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) [0.00] Enabling APIC mode: Flat. Using 1 I/O APICs [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Allocating PCI resources starting at 2000 (gap: 1000:effbd000) [0.00] swsusp: Registered nosave memory region: 0009f000 - 000a [0.00] swsusp: Registered nosave memory region: 000a - 000e8000 [0.00] swsusp: Registered nosave memory region: 000e8000 - 0010 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65009 [0.00] Kernel command line: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.gz console=ttyS0 [0.00] Enabling fast FPU save and restore... done. [0.00] Enabling unmasked SIMD FPU exception support... done. [0.00] Initializing CPU#0 [0.00] PID hash table entries: 1024 (order: 10, 4096 bytes) [0.00] Detected 3002.716 MHz processor. [ 18.835013] Console: colour VGA+ 80x25 [ 18.835162] console [ttyS0] enabled [ 18.977947] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 18.980655] Inode-cache hash table entries: 16384
Re: [kvm-devel] Protected mode transitions and big real mode... still an issue
On Mon, 5 May 2008 16:29:21 +0300
Mohammed Gamal [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 3:57 PM, Anthony Liguori [EMAIL PROTECTED] wrote:
WinXP fails to boot with your patch applied too. FWIW, Ubuntu 8.04 has
a fixed version of gfxboot that doesn't do nasty things with SS on
privileged mode transitions.
WinXP fails with the patch applied too. Ubuntu 7.10 live CD and
FreeDOS don't boot but complain about instruction mov 0x11,sreg not
being emulated.
Can you try with this one please?
On my computer it boots ubuntu-8.04-desktop-i386.iso liveCD and also
openSUSE-10.3-GM-x86_64-mini.iso
I will try FreeDOS and WinXP if I can find one ;)
Regards,
Guillaume
---
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 26c4f02..6e76c2e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1272,7 +1272,9 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
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);
+#endif
vmcs_write32(GUEST_SS_AR_BYTES, 0x93);
vmcs_write16(GUEST_CS_SELECTOR,
@@ -2633,6 +2635,73 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
return 1;
}
+static int invalid_guest_state(struct kvm_vcpu *vcpu,
+ struct kvm_run *kvm_run, u32 failure_reason)
+{
+ u16 ss, cs;
+ u8 opcodes[4];
+ unsigned long rip = vcpu-arch.rip;
+ unsigned long rip_linear;
+
+ ss = vmcs_read16(GUEST_SS_SELECTOR);
+ cs = vmcs_read16(GUEST_CS_SELECTOR);
+
+ if ((ss 0x03) != (cs 0x03)) {
+ int err;
+ rip_linear = rip + vmx_get_segment_base(vcpu, VCPU_SREG_CS);
+ emulator_read_std(rip_linear, (void *)opcodes, 4, vcpu);
+#if 0
+ printk(KERN_INFO emulation at (%lx) rip %lx: %02x %02x %02x
%02x\n,
+ rip_linear,
+ rip, opcodes[0], opcodes[1], opcodes[2],
opcodes[3]);
+#endif
+ err = emulate_instruction(vcpu, kvm_run, 0, 0, 0);
+ switch (err) {
+ case EMULATE_DONE:
+#if 0
+ printk(KERN_INFO successfully emulated
instruction\n);
+#endif
+ return 1;
+ case EMULATE_DO_MMIO:
+ printk(KERN_INFO mmio?\n);
+ return 0;
+ default:
+ kvm_report_emulation_failure(vcpu, vmentry
failure);
+ break;
+ }
+ }
+
+ kvm_run-exit_reason = KVM_EXIT_UNKNOWN;
+ kvm_run-hw.hardware_exit_reason = failure_reason;
+ return 0;
+}
+
+static int handle_vmentry_failure(struct kvm_vcpu *vcpu,
+ struct kvm_run *kvm_run,
+ u32 failure_reason)
+{
+ unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
+#if 0
+ printk(KERN_INFO Failed vm entry (exit reason 0x%x) , failure_reason);
+#endif
+ switch (failure_reason) {
+ case EXIT_REASON_INVALID_GUEST_STATE:
+#if 0
+ printk(invalid guest state \n);
+#endif
+ return invalid_guest_state(vcpu, kvm_run,
failure_reason);
+ case EXIT_REASON_MSR_LOADING:
+ printk(caused by MSR entry %ld loading.\n,
exit_qualification);
+ break;
+ case EXIT_REASON_MACHINE_CHECK:
+ printk(caused by machine check.\n);
+ break;
+ default:
+ printk(reason not known yet!\n);
+ break;
+ }
+ return 0;
+}
/*
* The exit handlers return 1 if the exit was handled fully and guest execution
* may resume. Otherwise they set the kvm_run parameter to indicate what needs
@@ -2694,6 +2763,12 @@ static int kvm_handle_exit(struct kvm_run *kvm_run,
struct kvm_vcpu *vcpu)
exit_reason != EXIT_REASON_EPT_VIOLATION))
printk(KERN_WARNING %s: unexpected, valid vectoring info and
exit reason is 0x%x\n, __func__, exit_reason);
+
+ if ((exit_reason VMX_EXIT_REASONS_FAILED_VMENTRY)) {
+ exit_reason = ~VMX_EXIT_REASONS_FAILED_VMENTRY;
+ return handle_vmentry_failure(vcpu, kvm_run, exit_reason);
+ }
+
if (exit_reason kvm_vmx_max_exit_handlers
kvm_vmx_exit_handlers[exit_reason])
return kvm_vmx_exit_handlers[exit_reason](vcpu, kvm_run);
diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h
index 79d94c6..2cebf48 100644
--- a/arch/x86/kvm/vmx.h
+++ b/arch/x86/kvm/vmx.h
@@ -238,7 +238,10 @@ enum vmcs_field {
#define EXIT_REASON_IO_INSTRUCTION 30
#define EXIT_REASON_MSR_READ31
#define
Re: [kvm-devel] Protected mode transitions and big real mode... still an issue
On Tue, 06 May 2008 09:30:44 -0500 Anthony Liguori [EMAIL PROTECTED] wrote: 8.04 is not a good test-case. 7.10 is what you want to try. Oh yes you're right. I tried 8.04 because Balaji had problems to boot it with the patch. The good news is, 7.10 appears to work! The bad news is that about 20% of the time, it crashes and displays the following: kvm_run: failed entry, reason 5 kvm_run returned -8 So something appears to be a bit buggy. Still, very good work! I can see the problem with openSuse10.3 too but no so often I'm looking for this issue. Thank you for the 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] Protected mode transitions and big real mode... still an issue
On Thu, 1 May 2008 16:13:31 -0300
Marcelo Tosatti [EMAIL PROTECTED] wrote:
The code sequence is:
8235: 66 data16
8236: 0f 22 c0mov%eax,%cr0
8239: ea 3e 02 00 08 b8 00ljmp $0xb8,$0x800023e
So it switches to realmode and then does a ljmp. Problem is that you're
using the segment selector as a GDT index, but in realmode it should be
shifted left by 4 to determine the segment base address. Following patch
makes Plan9 happy.
Other than that, load_segment_descriptor() can return a positive error
on failure, should do a proper check.
Index: kvm/arch/x86/kvm/x86_emulate.c
===
--- kvm.orig/arch/x86/kvm/x86_emulate.c
+++ kvm/arch/x86/kvm/x86_emulate.c
@@ -1755,7 +1755,10 @@ special_insn:
goto cannot_emulate;
}
sel = insn_fetch(u16, 2, c-eip);
- if (load_segment_descriptor(ctxt-vcpu, sel, 9, VCPU_SREG_CS)
0) {
+ if (ctxt-mode == X86EMUL_MODE_REAL)
+ eip |= (sel 4);
+ else if (load_segment_descriptor(ctxt-vcpu, sel, 9,
+ VCPU_SREG_CS) 0) {
DPRINTF(jmp far: Failed to load CS descriptor\n);
goto cannot_emulate;
}
Thank you Marcelo for the report. Unfortunately it is not the same
problem I'm seeing. The problem I have now is that I can boot until the
gfxboot screen but when I choose to install openSuse it generates a
kernel panic like this:
[EMAIL PROTECTED]/local/kvm-userspace.git/bin]$ ./qemu-system-x86_64
-hda ~/disk_images/hd_50G.qcow2 -cdrom
/images_iso/openSUSE-10.3-GM-x86_64-mini.iso -boot d -s -m 1024 -serial stdio
Linux version 2.6.22.5-31-default ([EMAIL PROTECTED]) (gcc version 4.2.1 (SUSE
Linux)) #1 SMP 2007/09/21 22:29:00 UTC
Command line: BOOT_IMAGE=linux initrd=initrd,08000600.spl splash=silent
vga=0x314 install=slp:/ console=ttyS0
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0009fc00 - 000a (reserved)
BIOS-e820: 000e8000 - 0010 (reserved)
BIOS-e820: 0010 - 3fff (usable)
BIOS-e820: 3fff - 4000 (ACPI data)
BIOS-e820: fffbd000 - 0001 (reserved)
end_pfn_map = 1048576
DMI 2.4 present.
ACPI: RSDP 000FB450, 0014 (r0 QEMU )
ACPI: RSDT 3FFF, 002C (r1 QEMU QEMURSDT1 QEMU1)
ACPI: FACP 3FFF002C, 0074 (r1 QEMU QEMUFACP1 QEMU1)
ACPI: DSDT 3FFF0100, 2464 (r1 BXPC BXDSDT1 INTL 20061109)
ACPI: FACS 3FFF00C0, 0040
ACPI: APIC 3FFF2568, 00E0 (r1 QEMU QEMUAPIC1 QEMU1)
No NUMA configuration found
Faking a node at -3fff
Bootmem setup node 0 -3fff
No mptable found.
Zone PFN ranges:
DMA 0 - 4096
DMA324096 - 1048576
Normal1048576 - 1048576
early_node_map[2] active PFN ranges
0:0 - 159
0: 256 - 262128
ACPI: PM-Timer IO Port: 0xb008
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] disabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] disabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] disabled)
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x09] disabled)
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] disabled)
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0b] disabled)
ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0c] disabled)
ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0d] disabled)
ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0e] disabled)
ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0f] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 0009f000 - 000a
swsusp: Registered nosave memory region: 000a - 000e8000
swsusp: Registered nosave memory region: 000e8000 - 0010
Allocating PCI resources starting at 5000 (gap: 4000:bffbd000)
SMP: Allowing 16 CPUs, 15 hotplug CPUs
PERCPU: Allocating 50296 bytes of per cpu data
Built 1 zonelists. Total pages: 257180
Kernel command line: BOOT_IMAGE=linux initrd=initrd,08000600.spl
Re: [kvm-devel] Protected mode transitions and big real mode... still an issue
On Sat, 3 May 2008 13:56:56 +0530 Balaji Rao [EMAIL PROTECTED] wrote: With your patch applied ubuntu 8.04 livecd fails to boot. Not any better with Marcelo's patch on top. Hi Balaji, And without the patch, can you boot the ubuntu 8.04 livecd? 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] Real Mode Improvement on Intel Hosts - GSoC Project
On Thu, 24 Apr 2008 11:05:39 -0500
Anthony Liguori [EMAIL PROTECTED] wrote:
The first stage is to detect vmentry failures and run x86_emulate() for
a single instruction. If you look at the mailing list, you'll see
patches from myself and Guillaume. This should be enough to allow most
Ubuntu installer CDs to work under KVM.
Howdy,
Here is the last patch I have. It can detects a vmentry failure and it
emulates one instruction. I added the emulation of several instructions
like ljmp, mov Sreg, reg, mov reg, Sreg... The problem I'm
working on is that once I entered in emulation of real mode I do not
manage to recover a VMX friendly state (in my case cs.rpl ==
ss.rpl). So I emulate more and more instructions.
I added a trace to see instructions that are emulated (emulation of
0xa8 is in progress so it currently fails):
[60108.040894] emulation at (46e53) rip 6e13: ea 18 6e 18
[60108.072108] emulation at (46e58) rip 6e18: 66 b8 20 00
[60108.103997] emulation at (46e5c) rip 6e1c: 8e d8 8c d0
[60108.148114] emulation at (46e5e) rip 6e1e: 8c d0 81 e4
[60108.180117] emulation at (46e60) rip 6e20: 81 e4 ff ff
[60108.212008] emulation at (46e66) rip 6e26: c1 e0 04 01
[60108.244926] emulation at (46e69) rip 6e29: 01 c4 66 b8
[60108.272948] emulation at (46e6b) rip 6e2b: 66 b8 08 00
[60108.304953] emulation at (46e6f) rip 6e2f: 8e d0 8e c0
[60108.348973] emulation at (46e71) rip 6e31: 8e c0 8e e0
[60108.396965] emulation at (46e73) rip 6e33: 8e e0 8e e8
[60108.445002] emulation at (46e75) rip 6e35: 8e e8 58 66
[60108.489021] emulation at (46e77) rip 6e37: 58 66 9d 66
[60108.521028] emulation at (46e78) rip 6e38: 66 9d 66 c3
[60108.552979] emulation at (46e7a) rip 6e3a: 66 c3 66 9c
[60108.581048] emulation at (40e2a) rip dea: be 29 0a 00
[60108.613033] emulation at (40e2f) rip def: e8 41 12 00
[60108.644970] emulation at (42075) rip 2035: c6 05 84 07
[60108.673038] emulation at (4207c) rip 203c: e8 18 01 00
[60108.705039] emulation at (42199) rip 2159: 31 c0 80 3d
[60108.736998] emulation at (4219b) rip 215b: 80 3d 86 07
[60108.765041] emulation at (421a2) rip 2162: 74 01 26 ac
[60108.797044] emulation at (421a5) rip 2165: ac c3 80 3d
[60108.829033] emulation at (421a6) rip 2166: c3 80 3d 86
[60108.857068] emulation at (42081) rip 2041: 09 c0 0f 84
[60108.889053] emulation at (42083) rip 2043: 0f 84 0f 01
[60108.921054] emulation at (42198) rip 2158: c3 31 c0 80
[60108.949076] emulation at (40e34) rip df4: 26 66 ff 35
[60108.981077] emulation at (40e3c) rip dfc: 66 8f 05 d0
[60109.013011] emulation at (40e43) rip e03: a1 b4 00 00
[60109.041079] emulation at (40e48) rip e08: 26 8a 40 03
[60109.073039] emulation at (40e4c) rip e0c: a8 01 74 4c
[60109.101078] emulation failed (vmentry failure) rip e0c a8 01 74 4c
So as we can see the first emulated instruction is the ljump and after
we emulate gfxboot loader instruction. I suspect a problem with an
update of SS segment or something like that in instructions that I
emulate.
I paste the patch. Don't worry about the last modification of the two
header files it's not related to real mode emulation.
Regards,
Guillaume
---
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 8e5d664..2c4c14d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1183,7 +1183,9 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
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);
+#endif
vmcs_write32(GUEST_SS_AR_BYTES, 0x93);
vmcs_write16(GUEST_CS_SELECTOR,
@@ -2323,6 +2325,53 @@ static int handle_task_switch(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
return kvm_task_switch(vcpu, tss_selector, reason);
}
+static int handle_vmentry_failure(struct kvm_vcpu *vcpu,
+ struct kvm_run *kvm_run, u32 failure_reason)
+{
+ u16 ss, cs;
+ u8 opcodes[4];
+ unsigned long rip = vcpu-arch.rip;
+ unsigned long rip_linear;
+
+ ss = vmcs_read16(GUEST_SS_SELECTOR);
+ cs = vmcs_read16(GUEST_CS_SELECTOR);
+
+ if ((ss 0x03) != (cs 0x03)) {
+ int err;
+
+#if 0
+ printk(KERN_INFO vmentry failure because ss.cpl != cs.cpl\n);
+#endif
+ rip_linear = rip + vmx_get_segment_base(vcpu, VCPU_SREG_CS);
+ emulator_read_std(rip_linear, (void *)opcodes, 4, vcpu);
+ printk(KERN_INFO emulation at (%lx) rip %lx: %02x %02x %02x
%02x\n,
+ rip_linear,
+ rip, opcodes[0], opcodes[1], opcodes[2],
opcodes[3]);
+ err = emulate_instruction(vcpu, kvm_run, 0, 0, 0);
+ switch (err) {
+ case EMULATE_DONE:
+#if 0
+ printk(KERN_INFO successfully emulated instruction\n);
+#endif
+ return 1;
+ case EMULATE_DO_MMIO:
+ printk(KERN_INFO
Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project
On Fri, 25 Apr 2008 09:51:04 +0300 Avi Kivity [EMAIL PROTECTED] wrote: [60108.040894] emulation at (46e53) rip 6e13: ea 18 6e 18 Here cs.rpl == cpl == 0 [60108.072108] emulation at (46e58) rip 6e18: 66 b8 20 00 [60108.103997] emulation at (46e5c) rip 6e1c: 8e d8 8c d0 [60108.148114] emulation at (46e5e) rip 6e1e: 8c d0 81 e4 [60108.180117] emulation at (46e60) rip 6e20: 81 e4 ff ff [60108.212008] emulation at (46e66) rip 6e26: c1 e0 04 01 [60108.244926] emulation at (46e69) rip 6e29: 01 c4 66 b8 [60108.272948] emulation at (46e6b) rip 6e2b: 66 b8 08 00 mov $8, %eax [60108.304953] emulation at (46e6f) rip 6e2f: 8e d0 8e c0 mov %eax, %ss Here, ss.rpl == 0 Yes, thus ss.rpl should be equal to cs.rpl (both equal to 0) and we should be in VMX friendly state. Mmmh, that means I made a mistake in the implementation of 0xb8 or 0x8e instruction. I'm investigating, thanks for your help. 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
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
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
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
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
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
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] How guest virtual address is translated to physical address?
On Wed, 02 Apr 2008 10:22:45 -0500 Anthony Liguori [EMAIL PROTECTED] wrote: We can then obtain the faulting virtual address from CR2 in the host and walk the guest's page table to determine what guest physical address should be mapped at that guest virtual address (if any at all). [...] I think what you're missing is that while the guest is running, it's CR3 does not point to it's own page table but rather to the shadow page table. We intercept CR3 reads to pretend to the guest that it's page table is, in fact, installed but it's really the shadow page table that's in the hardware register. Thank you very much for the explanations. You're right, I missed that CR3 points to the shadow page table. So it means that guest page table is not really used for translating guest virtual address to real physical address. If the guest page table is not used, why hyupervisor must find the guest physical address? I mean if with the shadow page table we can translate guest virtual address to real physical address it's not necessary to know the guest physical address. Is it only for checks? Regards, Guillaume - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] How guest virtual address is translated to physical address?
Hello, I have a question about how guest page table and shadow page table work together and more precisely, about how host is involved when guest access a page that it's already in the page table. The guest maintains its page table to translate guest virtual address to guest physical address. It uses the MMU and cr3 register for the translation. When there is a page fault, the host gets involved and it catches the guest physical address (by walking through the guest page table?) and fills its shadow page table. Thus the host can make the translation from guest physical address to physical address. Now, if the guest reads the same page, the PTE will point to guest physical address but there will not be any page fault so the host will not be involved in the translation (not so sure). I don't see how the guest virtual address will be translated to physical address? I miss something but I don't see what. Thanks for your help, Guillaume - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] catch vmentry failure (was enable gfxboot on VMX)
On Mon, 18 Feb 2008 10:39:31 +0100
Alexander Graf [EMAIL PROTECTED] wrote:
So if you want to see a VMentry failure, just remove the SS patching
and you'll see one. My guess would be that you see a lot of problems
with otherwise working code too then, though, as SS can be anything in
that state.
So I made some tests and you were right, removing the SS patching
showed VM entry failure but it also generated lots of problems. Thus I
tried to modify a little bit the code and with the following patch (see
the end of the email) I can detect VM Entry failures without generating
other problems. It works when you use a distribution that is
big-real-mode free. I pasted the patch just to show the idea.
It's interesting because we can continue to use the virtual mode for the
majority of distribution and we can detect when a VM entry failure is
detected it means that we need to switch from virtual mode to full real
mode emulation. Such failure is caught in handle_vmentry_failure() when
patch applied. If it's doable, the next step is the modification of the
SS segment selector to succeed the vm-entry and the switch from virtual
mode to a real mode emulation that could be done in
handle_vmentry_failure(). Does it make sense?
Regards,
Guillaume
---
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 46e0e58..c2c3897 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1166,15 +1166,13 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
(vmcs_readl(CR4_READ_SHADOW) X86_CR4_VME));
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);
- vmcs_write16(GUEST_SS_SELECTOR, 0);
- vmcs_write32(GUEST_SS_AR_BYTES, 0x93);
-
vmcs_write16(GUEST_CS_SELECTOR,
vmcs_read16(GUEST_CS_SELECTOR) ~SELECTOR_RPL_MASK);
vmcs_write32(GUEST_CS_AR_BYTES, 0x9b);
@@ -1228,20 +1226,12 @@ static void enter_rmode(struct kvm_vcpu *vcpu)
vmcs_writel(GUEST_CR4, vmcs_readl(GUEST_CR4) | X86_CR4_VME);
update_exception_bitmap(vcpu);
- vmcs_write16(GUEST_SS_SELECTOR, vmcs_readl(GUEST_SS_BASE) 4);
- vmcs_write32(GUEST_SS_LIMIT, 0x);
- vmcs_write32(GUEST_SS_AR_BYTES, 0xf3);
-
- vmcs_write32(GUEST_CS_AR_BYTES, 0xf3);
- vmcs_write32(GUEST_CS_LIMIT, 0x);
- if (vmcs_readl(GUEST_CS_BASE) == 0x)
- vmcs_writel(GUEST_CS_BASE, 0xf);
- vmcs_write16(GUEST_CS_SELECTOR, vmcs_readl(GUEST_CS_BASE) 4);
-
+ fix_rmode_seg(VCPU_SREG_CS, vcpu-arch.rmode.cs);
fix_rmode_seg(VCPU_SREG_ES, vcpu-arch.rmode.es);
fix_rmode_seg(VCPU_SREG_DS, vcpu-arch.rmode.ds);
fix_rmode_seg(VCPU_SREG_GS, vcpu-arch.rmode.gs);
fix_rmode_seg(VCPU_SREG_FS, vcpu-arch.rmode.fs);
+ fix_rmode_seg(VCPU_SREG_SS, vcpu-arch.rmode.ss);
kvm_mmu_reset_context(vcpu);
init_rmode_tss(vcpu-kvm);
@@ -2257,6 +2247,39 @@ static int (*kvm_vmx_exit_handlers[])(struct kvm_vcpu
*vcpu,
static const int kvm_vmx_max_exit_handlers =
ARRAY_SIZE(kvm_vmx_exit_handlers);
+static int handle_vmentry_failure(u32 exit_reason, struct kvm_vcpu *vcpu)
+{
+ unsigned long exit_qualification = vmcs_read64(EXIT_QUALIFICATION);
+ u32 info_field = vmcs_read32(VMX_INSTRUCTION_INFO);
+ unsigned int basic_exit_reason = (uint16_t) exit_reason;
+
+ printk(%s: exit reason 0x%x \n, __FUNCTION__, exit_reason);
+ printk(%s: vmentry failure reason %u \n, __FUNCTION__,
basic_exit_reason);
+ printk(%s: VMX-instruction Information field 0x%x \n, __FUNCTION__,
info_field);
+
+ switch (basic_exit_reason) {
+ case EXIT_REASON_INVALID_GUEST_STATE:
+ printk(caused by invalid guest state (%ld).\n,
exit_qualification);
+ /* At this point we need to modify SS selector to pass
vmentry test.
+* This modification prevent the usage of virtual mode
to emulate real
+* mode so we need to pass in big real mode emulation
+* with somehting like:
+* vcpu-arch.rmode.emulate = 1
+*/
+ break;
+ case EXIT_REASON_MSR_LOADING:
+ printk(caused by MSR entry %ld loading.\n,
exit_qualification);
+ break;
+ case EXIT_REASON_MACHINE_CHECK:
+ printk(caused by machine check.\n);
+ break;
+ default:
+ printk(reason not known yet!\n);
+ break;
+ }
+ return 0;
+}
+
/*
* The guest has exited. See if we can
Re: [kvm-devel] [PATCH] enable gfxboot on VMX
On Sat, 16 Feb 2008 14:34:09 +0100
Alexander Graf [EMAIL PROTECTED] wrote:
Whenever the register state becomes consistent with VT again.
vmx_set_segment() looks like the right point for turning it off.
Sounds good. As basically the only problem we have are the sanity
checks done on VMENTER, this should work.
Hello,
I tried to detect VMentry failure in order to do real mode emulation.
I tested the patch (pasted at the end of this message) with the
installation of OpenSuse 10.3 but it failed to detect the VMentry
failure. I suspect that on my computer the failure is not due to a
VMentry failure. Can you test the patch and tell me if it detects a
VMentry failure?
Thanks for your help,
Regards,
Guillaume
---
Index: kvm/arch/x86/kvm/vmx.c
===
--- kvm.orig/arch/x86/kvm/vmx.c 2008-02-18 09:22:53.0 +0100
+++ kvm/arch/x86/kvm/vmx.c 2008-02-18 09:43:13.0 +0100
@@ -2255,6 +2255,15 @@
static const int kvm_vmx_max_exit_handlers =
ARRAY_SIZE(kvm_vmx_exit_handlers);
+static int kvm_handle_vmentry_failure(struct kvm_run *kvm_run, struct kvm_vcpu
*vcpu)
+{
+ printk(KERN_WARNING VMENTRY failure detected \n);
+ if (vcpu-arch.rmode.active)
+ printk(KERN_WARNING Big Real Mode emulation needed \n);
+
+ return 0;
+}
+
/*
* The guest has exited. See if we can fix it or if we need userspace
* assistance.
@@ -2265,6 +2274,9 @@
struct vcpu_vmx *vmx = to_vmx(vcpu);
u32 vectoring_info = vmx-idt_vectoring_info;
+ if (unlikely(exit_reason VMX_EXIT_REASONS_FAILED_VMENTRY))
+ return kvm_handle_vmentry_failure(kvm_run, vcpu);
+
if (unlikely(vmx-fail)) {
kvm_run-exit_reason = KVM_EXIT_FAIL_ENTRY;
kvm_run-fail_entry.hardware_entry_failure_reason
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ToDo] Real Mode Support
On Sun, 10 Feb 2008 13:44:05 +0200 Avi Kivity [EMAIL PROTECTED] wrote: Anthony Liguori wrote: So what we would like to do, is instead of setting up vm86 mode for the guest to execute real mode, use x86_emulate() to just emulate the code. This means that we wouldn't be using the vmlaunch instruction when in real mode and instead would be doing an x86_emulate() loop. As using the emulator is likely to be slower than VT, we can call the emulator only if we are in a VT unfriendly state, so the code might look like if (vmx-rmode.active big_real_mode(vmx)) ... In addition, there are some protected-mode states that VT can't handle (cs.rpl != ss.rpl IIRC) so we can emulate those cases as well. To improve speed, we may want to emulate 1 instruction per iteration. So the plan is to keep the usage of vm86 mode until we detect a VT unfriendly state. I think about a VMentry failure to detect this kind of state? Then, when we are in big_real_mode state, we emulate the code as suggested by Avi with the optimisation that consists to emulate more than one instruction per iteration. Best regards, Guillaume - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ToDo] Real Mode Support
On Wed, 06 Feb 2008 10:52:54 +0200 Izik Eidus [EMAIL PROTECTED] wrote: i am not expert for the emulator area, but as far as i remember: virtual 8086 have some checks related to segments (the big mode problem), it mean that for some addresses it wont be able to execute anything, you will just get vmexit right away, therefor you need a full functional emulator that will handle everything there. Oh thanks, I remember now. The problem seems to be with the descriptor cache register. In protected mode and also in virtual mode the descriptor cache register is fully loaded each time a segment register is loaded. It's not the case in real mode. So every program that uses this feature (the big real mode) will not work under vm8086. Thus we need to remove the usage of the virtual mode and instead we need to fully emulate the real mode in order to be big real mode compliant. Does somebody know if there are already some patches or some other stuff about big real mode support? Regards, Guillaume - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Where are vmentry failure caugth?
On Sat, 12 Jan 2008 14:34:12 -0600 Anthony Liguori [EMAIL PROTECTED] wrote: What version of gfxboot does openSUSE 10.3 use? gfxboot was broken for KVM until very recently. This is probably what you're seeing. I don't know what version it is but do you talk about the bug due to the wrong RPL value in the SS selector that produces a VMentry failure? Because my problem is here. I thought that I could catch the VMentry failure by added a test like if (unlikely(exit_reason VMX_EXIT_REASONS_FAILED_VMENTRY)) in kvm_handle_exit(). Thus I tried to start the openSUSE 10.3 with the old gfxboot to test the VMentry failure but I cannot catch it and that's why I'm a little lost. I will try to understand the first handle_exception message as suggested by Avi. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Where are vmentry failure caugth?
On Thu, 10 Jan 2008 11:19:58 +0100
Guillaume Thouvenin [EMAIL PROTECTED] wrote:
I tried but it didn't catch any vmentry failures (and I know that
there is at least one during the test).
I think that there is a vmentry failure because qemu-system-x86_64
crashes with following error:
exception 13 (33)
I interpreted this as a vmentry failure because 33 is the exit reason
for a vmentry failure. The problem is that I don't find how to catch it
in kvm. I thought that something like:
static int
kvm_handle_exit(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
{
u32 exit_reason = vmcs_read32(VM_EXIT_REASON);
struct vcpu_vmx *vmx = to_vmx(vcpu);
u32 vectoring_info = vmx-idt_vectoring_info;
if ( unlikely(exit_reason VMX_EXIT_REASONS_FAILED_VMENTRY) )
// I should get it here no?
...
}
but exit_reason is never equal to VMX_EXIT_REASONS_FAILED_VMENTRY. Does
it mean that what I interpret as a vmentry failure due to invalid guest
state is in fact due to something else.
Any hints to catch the vmentry failure due to invalid guest state in
kvm?
Thanks,
Guillaume
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Where are vmentry failure caugth?
On Thu, 10 Jan 2008 17:32:35 +0200 Avi Kivity [EMAIL PROTECTED] wrote: I think 33 is the error code, which means we got a general protection fault while accessing segment 0x33. What guest code is running when this happens? The dump sometimes includes the current code. When it happened I started an openSUSE-10.3 installation. Here is the complete dump: [guill]$ ./qemu-system-x86_64 -hda ~/disk_images/openSUSE-10.3.qcow2 -cdrom ~/iso_images/openSUSE-10.3-GM-x86_64-mini.iso -boot d -m 1024 exception 13 (33) rax 0671 rbx 0080 rcx rdx 13ca rsi 00055e1c rdi 00055e1d rsp fffa0080 rbp 200b r8 r9 r10 r11 r12 r13 r14 r15 rip b071 rflags 00033096 cs 4004 (00040040/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds 4004 (00040040/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 00ff (0ff0/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss ff11 (000ff110/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 3002 (00030020/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (fffbd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 40920/47 idt 0/ cr0 6010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 17 06 29 4b 01 18 eb 18 a8 25 aa 19 28 4c 01 28 4d 01 01 17 -- 0f 17 0f 01 17 0f 17 12 01 17 2c 25 4b 19 21 00 02 17 1a 94 0a 76 67 61 3d 30 78 25 78 20 Aborted In the console I got: [86955.117391] handle_exception: unexpected, vectoring info 0x8306 intr info 0x8b0d [86955.193194] pending exception: not handled yet [86955.219948] pending exception: not handled yet -- Guillaume Thouvenin - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 2 of 2] Emulate CMPS instruction
On Fri, 23 Nov 2007 19:54:46 +0200 Avi Kivity [EMAIL PROTECTED] wrote: No new macros in the emulator please. Just inline it at the callsite. Ok I make the modification. : c-dst.bytes); break; case 0xa6 ... 0xa7: /* cmps */ - DPRINTF(Urk! I don't handle CMPS.\n); - goto cannot_emulate; + c-src.type = OP_NONE; Shouldn't this be OP_MEM? As bytes to be compared are just read I use OP_NONE to disable writeback. + c-dst.bytes = (c-d ByteOp) ? 1 : c-op_bytes; + c-dst.ptr = (unsigned long *)register_address( + ctxt-es_base, + c-regs[VCPU_REGS_RSI]); + + DPRINTF(cmps: mem1=0x%p mem2=0x%p\n, c-src.ptr, c-dst.ptr); + Where is the actual memory access? Oops I missed that point I fix that immediately. Thanks for your help, Guillaume - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 2 of 2][rewritten] Emulate CMPS instruction
This patch emulates the CMPS instruction. I made corrections requested
by Avi (removed macro and added the memory access). I fixed an
inversion between arguments VCPU_REGS_RSI and VCPU_REGS_RDI in function
register_address(). I also added the test if DS segment is overridden
with a segment override prefix (ES segment cannot be overriden).
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c | 58 +++--
1 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index cee60eb..9eb9922 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1540,10 +1540,31 @@ special_insn:
break;
}
if (c-rep_prefix) {
+ /* All REP prefixes have the same first termination condition */
if (c-regs[VCPU_REGS_RCX] == 0) {
ctxt-vcpu-rip = c-eip;
goto done;
}
+ /* The second termination condition only applies for REPE
+* and REPNE. Test if the repeat string operation prefix is
+* REPE/REPZ or REPNE/REPNZ and if it's the case it tests the
+* corresponding termination condition according to:
+* - if REPE/REPZ and ZF = 0 then done
+* - if REPNE/REPNZ and ZF = 1 then done
+*/
+ if ((c-b == 0xa6) || (c-b == 0xa7) ||
+ (c-b == 0xae) || (c-b == 0xaf)) {
+ if ((c-rep_prefix == REPE_PREFIX)
+ ((ctxt-eflags EFLG_ZF) == 0)) {
+ ctxt-vcpu-rip = c-eip;
+ goto done;
+ }
+ if ((c-rep_prefix == REPNE_PREFIX)
+ ((ctxt-eflags EFLG_ZF) == EFLG_ZF)) {
+ ctxt-vcpu-rip = c-eip;
+ goto done;
+ }
+ }
c-regs[VCPU_REGS_RCX]--;
c-eip = ctxt-vcpu-rip;
}
@@ -1570,8 +1591,41 @@ special_insn:
: c-dst.bytes);
break;
case 0xa6 ... 0xa7: /* cmps */
- DPRINTF(Urk! I don't handle CMPS.\n);
- goto cannot_emulate;
+ c-src.type = OP_NONE; /* Disable writeback. */
+ c-src.bytes = (c-d ByteOp) ? 1 : c-op_bytes;
+ c-src.ptr = (unsigned long *)register_address(
+ c-override_base ? *c-override_base :
+ ctxt-ds_base,
+ c-regs[VCPU_REGS_RSI]);
+ if ((rc = ops-read_emulated((unsigned long)c-src.ptr,
+ c-src.val,
+ c-src.bytes,
+ ctxt-vcpu)) != 0)
+ goto done;
+
+ c-dst.type = OP_NONE; /* Disable writeback. */
+ c-dst.bytes = (c-d ByteOp) ? 1 : c-op_bytes;
+ c-dst.ptr = (unsigned long *)register_address(
+ ctxt-es_base,
+ c-regs[VCPU_REGS_RDI]);
+ if ((rc = ops-read_emulated((unsigned long)c-dst.ptr,
+ c-dst.val,
+ c-dst.bytes,
+ ctxt-vcpu)) != 0)
+ goto done;
+
+ DPRINTF(cmps: mem1=0x%p mem2=0x%p\n, c-src.ptr, c-dst.ptr);
+
+ emulate_2op_SrcV(cmp, c-src, c-dst, ctxt-eflags);
+
+ register_address_increment(c-regs[VCPU_REGS_RSI],
+ (ctxt-eflags EFLG_DF) ? -c-src.bytes
+ : c-src.bytes);
+ register_address_increment(c-regs[VCPU_REGS_RDI],
+ (ctxt-eflags EFLG_DF) ? -c-dst.bytes
+ : c-dst.bytes);
+
+ break;
case 0xaa ... 0xab: /* stos */
c-dst.type = OP_MEM;
c-dst.bytes = (c-d ByteOp) ? 1 : c-op_bytes;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch 1 of 2] Rename REP prefixes
This patch renames REP prefix with more suitable name.
Signed-off-by:: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c |4 ++--
drivers/kvm/x86_emulate.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index ff7010c..cee60eb 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -829,10 +829,10 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
c-lock_prefix = 1;
break;
case 0xf2: /* REPNE/REPNZ */
- c-rep_prefix = REPNE_REPNZ;
+ c-rep_prefix = REPNE_PREFIX;
break;
case 0xf3: /* REP/REPE/REPZ */
- c-rep_prefix = REP_REPE_REPZ;
+ c-rep_prefix = REPE_PREFIX;
break;
default:
goto done_prefixes;
diff --git a/drivers/kvm/x86_emulate.h b/drivers/kvm/x86_emulate.h
index 5ce4c0c..61762f9 100644
--- a/drivers/kvm/x86_emulate.h
+++ b/drivers/kvm/x86_emulate.h
@@ -162,8 +162,8 @@ struct x86_emulate_ctxt {
};
/* Repeat String Operation Prefix */
-#define REP_REPE_REPZ 1
-#define REPNE_REPNZ2
+#define REPE_PREFIX1
+#define REPNE_PREFIX 2
/* Execution mode, passed to the emulator. */
#define X86EMUL_MODE_REAL 0/* Real mode. */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch 0 of 2] Emulate CMPS instruction
Hello, This patch emulates the CMPS instruction. It should fix the openbsd bug opened in sourceforge (it does on my computer). There are two patches. The first one renames the REP prefix definition to be more comprehensive and the second one is the emulation of the CMPS instruction. Regards, Guillaume - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch 2 of 2] Emulate CMPS instruction
This patch emulates the CMPS instruction.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c | 54 +++--
1 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index cee60eb..db744cf 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -445,6 +445,29 @@ static u16 twobyte_table[256] = {
register_address_increment(c-eip, rel);\
} while (0)
+/* Test if the repeat string operation prefix is REPE/REPZ or
+ * REPNE/REPNZ and if it's the case it tests the corresponding
+ * termination condition according to:
+ * - if REPE/REPZ and ZF = 0 then done
+ * - if REPNE/REPNZ and ZF = 1 then done
+ */
+#define handle_rep_prefix(c)\
+ do {\
+ if ((c-b == 0xa6) || (c-b == 0xa7) || \
+ (c-b == 0xae) || (c-b == 0xaf)) { \
+ if ((c-rep_prefix == REPE_PREFIX)\
+ ((ctxt-eflags EFLG_ZF) == 0)) { \
+ ctxt-vcpu-rip = c-eip; \
+ goto done; \
+ } \
+ if ((c-rep_prefix == REPNE_PREFIX) \
+ ((ctxt-eflags EFLG_ZF) == EFLG_ZF)) {\
+ ctxt-vcpu-rip = c-eip; \
+ goto done; \
+ } \
+ } \
+ } while (0)
+
static int do_fetch_insn_byte(struct x86_emulate_ctxt *ctxt,
struct x86_emulate_ops *ops,
unsigned long linear, u8 *dest)
@@ -1540,10 +1563,15 @@ special_insn:
break;
}
if (c-rep_prefix) {
+ /* All REP prefixes have the same first termination condition */
if (c-regs[VCPU_REGS_RCX] == 0) {
ctxt-vcpu-rip = c-eip;
goto done;
}
+ /* The second termination condition only applies for REPE
+* and REPNE. handle_rep_prefix() macro deals with that.
+*/
+ handle_rep_prefix(c);
c-regs[VCPU_REGS_RCX]--;
c-eip = ctxt-vcpu-rip;
}
@@ -1570,8 +1598,30 @@ special_insn:
: c-dst.bytes);
break;
case 0xa6 ... 0xa7: /* cmps */
- DPRINTF(Urk! I don't handle CMPS.\n);
- goto cannot_emulate;
+ c-src.type = OP_NONE;
+ c-src.bytes = (c-d ByteOp) ? 1 : c-op_bytes;
+ c-src.ptr = (unsigned long *)register_address(
+ ctxt-ds_base,
+ c-regs[VCPU_REGS_RDI]);
+
+ c-dst.type = OP_NONE;
+ c-dst.bytes = (c-d ByteOp) ? 1 : c-op_bytes;
+ c-dst.ptr = (unsigned long *)register_address(
+ ctxt-es_base,
+ c-regs[VCPU_REGS_RSI]);
+
+ DPRINTF(cmps: mem1=0x%p mem2=0x%p\n, c-src.ptr, c-dst.ptr);
+
+ emulate_2op_SrcV(cmp, c-src, c-dst, ctxt-eflags);
+
+ register_address_increment(c-regs[VCPU_REGS_RDI],
+ (ctxt-eflags EFLG_DF) ? -c-dst.bytes
+ : c-dst.bytes);
+
+ register_address_increment(c-regs[VCPU_REGS_RSI],
+ (ctxt-eflags EFLG_DF) ? -c-dst.bytes
+ : c-dst.bytes);
+ break;
case 0xaa ... 0xab: /* stos */
c-dst.type = OP_MEM;
c-dst.bytes = (c-d ByteOp) ? 1 : c-op_bytes;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] make distinction between repeat prefixes F3 and F2
Hello,
CMPS and SCAS instructions accept repeat prefixes F3 and F2. So in
order to emulate those prefixed instructions we need to be able to know
if prefixes are REP/REPE/REPZ or REPNE/REPNZ. Currently kvm doesn't make
this distinction. This patch introduces this distinction.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c |4 +++-
drivers/kvm/x86_emulate.h |4
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index bebdcee..f8e7200 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -824,8 +824,10 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
c-lock_prefix = 1;
break;
case 0xf2: /* REPNE/REPNZ */
+ c-rep_prefix = REPNE_REPNZ;
+ break;
case 0xf3: /* REP/REPE/REPZ */
- c-rep_prefix = 1;
+ c-rep_prefix = REP_REPE_REPZ;
break;
default:
goto done_prefixes;
diff --git a/drivers/kvm/x86_emulate.h b/drivers/kvm/x86_emulate.h
index 31aa3e1..5ce4c0c 100644
--- a/drivers/kvm/x86_emulate.h
+++ b/drivers/kvm/x86_emulate.h
@@ -161,6 +161,10 @@ struct x86_emulate_ctxt {
struct decode_cache decode;
};
+/* Repeat String Operation Prefix */
+#define REP_REPE_REPZ 1
+#define REPNE_REPNZ2
+
/* Execution mode, passed to the emulator. */
#define X86EMUL_MODE_REAL 0/* Real mode. */
#define X86EMUL_MODE_PROT16 2/* 16-bit protected mode. */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] make distinction between repeat prefixes F3 and F2
On Thu, 22 Nov 2007 17:27:55 +0530 Amit Shah [EMAIL PROTECTED] wrote: Can you just rename this to REP and REPNE? Yes I can. I send the new patch. Does this fix the problems you saw with openbsd? No not yet. It will help to make the difference between REPE prefix and REPNE prefix because both can be added to the CMPS and SCAS instruction. To be able to boot OpenBSD41 properly we need to emulate CMPS. I replaced CMPS by a NOP instruction and it allows me to boot openbsd but it's not really an acceptable solution, it was just to see if that the emulation of CMPS instruction was the problem. Guillaume - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] make distinction between repeat prefixes F3 and F2
CMPS and SCAS instructions accept repeat prefixes REPE and REPNE. So in
order to emulate those prefixed instructions we need to be able to know
if prefixes are REP/REPE/REPZ or REPNE/REPNZ. Currently kvm doesn't
make this distinction. This patch introduces this distinction.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c |4 +++-
drivers/kvm/x86_emulate.h |4
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index bebdcee..3eae1b1 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -824,8 +824,10 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
c-lock_prefix = 1;
break;
case 0xf2: /* REPNE/REPNZ */
+ c-rep_prefix = REPNE;
+ break;
case 0xf3: /* REP/REPE/REPZ */
- c-rep_prefix = 1;
+ c-rep_prefix = REP;
break;
default:
goto done_prefixes;
diff --git a/drivers/kvm/x86_emulate.h b/drivers/kvm/x86_emulate.h
index 31aa3e1..2252989 100644
--- a/drivers/kvm/x86_emulate.h
+++ b/drivers/kvm/x86_emulate.h
@@ -161,6 +161,10 @@ struct x86_emulate_ctxt {
struct decode_cache decode;
};
+/* Repeat String Operation Prefix */
+#define REP1
+#define REPNE 2
+
/* Execution mode, passed to the emulator. */
#define X86EMUL_MODE_REAL 0/* Real mode. */
#define X86EMUL_MODE_PROT16 2/* 16-bit protected mode. */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] multiple allocation for vmcs or am i missing something.
On Thu, 8 Feb 2007 21:06:37 +0545 Manish Regmi [EMAIL PROTECTED] wrote: Later when vmx_create_vcpu is called, the vmcs area is allocated (again) and this time for the cpu the code is currently executing on. possibly it is already allocated. Is this a bug or i am missing something. Hello, I don't see where vmx_create_vcpu is called again. I think that it is called only once from 'r = kvm_arch_ops-vcpu_create(vcpu)'. Thus I don't think that vmcs area is allocated twice for each vcpu. Regards, Guillaume - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
