Poor Write I/O Performance on KVM-79
Hello! I have been experimenting with KVM and have been experiencing poor write I/O performance. I'm not sure whether I'm doing something wrong or if this is just the current state of things. While writing to the local array on the node running the guests I get about 200MB/s from dd (bs=1M count=1000) or about 90MB/s write performance from iozone (sequencial) when I write to a 2G file with a 16M record length. The node is an 8 disk system using 3ware in a RAID50 configuration. It has 8GB of RAM. The guests get much slower disk access. The guests are using file based backends (tried both qcow2 and raw) with virtio support. With no other activity on the machine, I get about 6 to 7MB/s write performance from iozone with the same test. Guests are running Debian lenny/sid with 2.6.26-1-686. I don't know whether this is because of context switching or what. Again, I'm wondering how I can improve this performance or if there is something I am doing wrong. As a side note, I have also noticed some weirdness with qcow2 files; some windows installations freeze and some disk corruption running iozone on Linux guests. All problems go away when I switch to raw image files though. I realize I take a hit by running file-based backends, and that the tests aren't altogether accurate because with 8GB of RAM, I'm not saturating the cache but they are still very disparate in numbers which concerns me. Finally, does anyone know if KVM is now fully supporting SCSI pass-through in KVM-79? Does this mean that I would vastly reduce context switching by using an LVM backend device for guests or am I misunderstanding the benefits of pass-through? This is the iozone command: # iozone -a -r 16M -g 2g -n 16g -m 2000 KVM command to launch guest: # /usr/bin/kvm -S -M pc -m 1024 -smp 1 -name demo4 \ -uuid 5b474147-f581-9a21-ac7d-cdd0ce881c5c -monitor pty -boot c \ -drive file=/iso/debian-testing-i386-netinst.iso,if=ide,media=cdrom,index=2 \ -drive file=/srv/demo/demo4.img,if=virtio,index=0,boot=on -net \ nic,macaddr=00:16:16:64:e6:de,vlan=0 -net \ tap,fd=15,script=,vlan=0,ifname=vnet1 -serial pty -parallel none \ -usb -vnc 0.0.0.0:1 -k en-us KVM/QEMU versions: ii kvm 79+dfsg-3 ii qemu 0.9.1-8 Node Kernel: 2.6.26-1-amd64 Thanks, -Alexander -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Ah, your approach is much better than mine.
Please ignore ours.
Best Regards
Haitao Shan
Leendert van Doorn wrote:
> I've been experimenting with passthru graphics for KVM and for that I
> needed to add PCI ROM support to QEMU. I went a slightly different
> route than Haitoa, I enabled the BIOS to do the PCI ROM mapping and
> initialization and added support for QEMU to fully implement the ROM
> BAR. This patch also uses the host BAR addresses in the guest for
> direct assigned devices, because (as Avi already pointed out) this is
> needed for more complex PCI cards such as graphics adapters. My patch
> also allows you to optionally specify the ROM image, which I found
> very useful for debugging.
>
> My ROMBIOS patches are probably more invasive than necessary. I found
> it cleaner (==easier to understand) to call the rombios from 32-bit
> mode than leave some droppings (option rom address, bdf) in the BIOS
> extended data segment. The other thing you notice is that I
> initialize the primary VGA ROM last. I found that this was necessary
> when emulating dual headed displays (one display on qemu's emulation
> window, the other the actual device).
>
> I've attached my patches.
>
> Note that I have not included the full graphics passthru patches yet.
> I have that working for the xorg ati drivers (and ATI's ATOMBIOS) but
> not for the closed sourced or Windows drivers yet. Let me know if you
> are interested in those patches.
>
> Leendert
>
>
> diff --git a/bios/rombios.c b/bios/rombios.c
> index b7a240f..c8ef8ac 100644
> --- a/bios/rombios.c
> +++ b/bios/rombios.c
> @@ -10130,7 +10130,7 @@ rombios32_real_mode:
>ret
>
> rombios32_gdt_48:
> - dw 0x30
> + dw 0x38
>dw rombios32_gdt
>dw 0x000f
>
> @@ -10141,6 +10141,7 @@ rombios32_gdt:
>dw 0x, 0, 0x9300, 0x00cf ; 32 bit flat data segment (0x18)
>dw 0x, 0, 0x9b0f, 0x ; 16 bit code segment base=0xf
> limit=0x
>dw 0x, 0, 0x9300, 0x ; 16 bit data segment base=0x0
> limit=0x + dw 0x, 0, 0x9b0e, 0x ; 16 bit code segment
> base=0xE limit=0x
> #endif // BX_ROMBIOS32
>
>
> @@ -10194,6 +10195,7 @@ no_serial:
>pop dx
>ret
>
> +#if !BX_ROMBIOS32
> rom_checksum:
>push ax
>push bx
> @@ -10266,7 +10268,6 @@ block_count_rounded:
>mov ax, #0xf000
>mov es, ax
>lea di, pnp_string
> -
>mov bp, sp ;; Call ROM init routine using seg:off on stack
>db 0xff ;; call_far ss:[bp+0]
>db 0x5e
> @@ -10348,6 +10349,7 @@ rom_scan_increment:
>xor ax, ax ;; Restore DS back to :
>mov ds, ax
>ret
> +#endif /* !BX_ROMBIOS32 */
>
> post_enable_cache:
>;; enable cache
> @@ -10652,12 +10654,6 @@ post_default_ints:
>;; PIC
>call post_init_pic
>
> - mov cx, #0xc000 ;; init vga bios
> - mov ax, #0xc780
> - call rom_scan
> -
> - call _print_bios_banner
> -
> #if BX_ROMBIOS32
>call rombios32_init
> #else
> @@ -10665,7 +10661,12 @@ post_default_ints:
>call pcibios_init_iomem_bases
>call pcibios_init_irqs
> #endif //BX_PCIBIOS
> -#endif
> + mov cx, #0xc000 ;; init vga bios
> + mov ax, #0xc780
> + call rom_scan
> +#endif //BX_ROMBIOS32
> +
> + call _print_bios_banner
>
>;;
>;; Floppy setup
> @@ -10698,9 +10699,11 @@ post_default_ints:
>
>call _init_boot_vectors
>
> +#if !BX_ROMBIOS32
>mov cx, #0xc800 ;; init option roms
>mov ax, #0xe000
>call rom_scan
> +#endif
>
> #if BX_ELTORITO_BOOT
>call _interactive_bootkey
> diff --git a/bios/rombios32.c b/bios/rombios32.c
> index 321563d..580aa17 100755
> --- a/bios/rombios32.c
> +++ b/bios/rombios32.c
> @@ -1,4 +1,4 @@
> -/
> +
> // $Id: rombios32.c,v 1.11 2007/08/03 13:56:13 vruppert Exp $
> /
> //
> @@ -679,6 +679,7 @@ typedef struct PCIDevice {
> int devfn;
> } PCIDevice;
>
> +static int pci_bios_nvga = 0;
> static uint32_t pci_bios_io_addr;
> static uint32_t pci_bios_mem_addr;
> static uint32_t pci_bios_bigmem_addr;
> @@ -736,7 +737,7 @@ static void pci_set_io_region_addr(PCIDevice *d,
> int region_num, uint32_t addr)
> old_addr = pci_config_readl(d, ofs);
>
> pci_config_writel(d, ofs, addr);
> -BX_INFO("region %d: 0x%08x\n", region_num, addr);
> +// BX_INFO("region %d: 0x%08x\n", region_num, addr);
>
> /* enable memory mappings */
> cmd = pci_config_readw(d, PCI_COMMAND);
> @@ -928,6 +929,7 @@ static void pci_bios_init_device(PCIDevice *d)
> }
> break;
> case 0x0300: /* Display controller - VGA compatible controller */
> + pci_bios_nvga++;
> if (vendor_id != 0x1234)
> goto default_map;
> /* VGA: map frame buffer to default Bochs VBE address */
> @@ -953,18 +955,21 @@ static void pci_bios_init_device(PCIDevice *d)
> default
RE: [PATCH][v2] kvm-userspace: Load PCI option ROMs
I've been experimenting with passthru graphics for KVM and for that I needed
to add PCI ROM support to QEMU. I went a slightly different route than
Haitoa, I enabled the BIOS to do the PCI ROM mapping and initialization and
added support for QEMU to fully implement the ROM BAR. This patch also uses
the host BAR addresses in the guest for direct assigned devices, because (as
Avi already pointed out) this is needed for more complex PCI cards such as
graphics adapters. My patch also allows you to optionally specify the ROM
image, which I found very useful for debugging.
My ROMBIOS patches are probably more invasive than necessary. I found it
cleaner (==easier to understand) to call the rombios from 32-bit mode than
leave some droppings (option rom address, bdf) in the BIOS extended data
segment. The other thing you notice is that I initialize the primary VGA ROM
last. I found that this was necessary when emulating dual headed displays
(one display on qemu's emulation window, the other the actual device).
I've attached my patches.
Note that I have not included the full graphics passthru patches yet. I have
that working for the xorg ati drivers (and ATI's ATOMBIOS) but not for the
closed sourced or Windows drivers yet. Let me know if you are interested in
those patches.
Leendert
diff --git a/bios/rombios.c b/bios/rombios.c
index b7a240f..c8ef8ac 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -10130,7 +10130,7 @@ rombios32_real_mode:
ret
rombios32_gdt_48:
- dw 0x30
+ dw 0x38
dw rombios32_gdt
dw 0x000f
@@ -10141,6 +10141,7 @@ rombios32_gdt:
dw 0x, 0, 0x9300, 0x00cf ; 32 bit flat data segment (0x18)
dw 0x, 0, 0x9b0f, 0x ; 16 bit code segment base=0xf
limit=0x
dw 0x, 0, 0x9300, 0x ; 16 bit data segment base=0x0 limit=0x
+ dw 0x, 0, 0x9b0e, 0x ; 16 bit code segment base=0xE
limit=0x
#endif // BX_ROMBIOS32
@@ -10194,6 +10195,7 @@ no_serial:
pop dx
ret
+#if !BX_ROMBIOS32
rom_checksum:
push ax
push bx
@@ -10266,7 +10268,6 @@ block_count_rounded:
mov ax, #0xf000
mov es, ax
lea di, pnp_string
-
mov bp, sp ;; Call ROM init routine using seg:off on stack
db 0xff ;; call_far ss:[bp+0]
db 0x5e
@@ -10348,6 +10349,7 @@ rom_scan_increment:
xor ax, ax ;; Restore DS back to :
mov ds, ax
ret
+#endif /* !BX_ROMBIOS32 */
post_enable_cache:
;; enable cache
@@ -10652,12 +10654,6 @@ post_default_ints:
;; PIC
call post_init_pic
- mov cx, #0xc000 ;; init vga bios
- mov ax, #0xc780
- call rom_scan
-
- call _print_bios_banner
-
#if BX_ROMBIOS32
call rombios32_init
#else
@@ -10665,7 +10661,12 @@ post_default_ints:
call pcibios_init_iomem_bases
call pcibios_init_irqs
#endif //BX_PCIBIOS
-#endif
+ mov cx, #0xc000 ;; init vga bios
+ mov ax, #0xc780
+ call rom_scan
+#endif //BX_ROMBIOS32
+
+ call _print_bios_banner
;;
;; Floppy setup
@@ -10698,9 +10699,11 @@ post_default_ints:
call _init_boot_vectors
+#if !BX_ROMBIOS32
mov cx, #0xc800 ;; init option roms
mov ax, #0xe000
call rom_scan
+#endif
#if BX_ELTORITO_BOOT
call _interactive_bootkey
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 321563d..580aa17 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -1,4 +1,4 @@
-/
+
// $Id: rombios32.c,v 1.11 2007/08/03 13:56:13 vruppert Exp $
/
//
@@ -679,6 +679,7 @@ typedef struct PCIDevice {
int devfn;
} PCIDevice;
+static int pci_bios_nvga = 0;
static uint32_t pci_bios_io_addr;
static uint32_t pci_bios_mem_addr;
static uint32_t pci_bios_bigmem_addr;
@@ -736,7 +737,7 @@ static void pci_set_io_region_addr(PCIDevice *d, int
region_num, uint32_t addr)
old_addr = pci_config_readl(d, ofs);
pci_config_writel(d, ofs, addr);
-BX_INFO("region %d: 0x%08x\n", region_num, addr);
+// BX_INFO("region %d: 0x%08x\n", region_num, addr);
/* enable memory mappings */
cmd = pci_config_readw(d, PCI_COMMAND);
@@ -928,6 +929,7 @@ static void pci_bios_init_device(PCIDevice *d)
}
break;
case 0x0300: /* Display controller - VGA compatible controller */
+ pci_bios_nvga++;
if (vendor_id != 0x1234)
goto default_map;
/* VGA: map frame buffer to default Bochs VBE address */
@@ -953,18 +955,21 @@ static void pci_bios_init_device(PCIDevice *d)
default_map:
/* default memory mappings */
for(i = 0; i < PCI_NUM_REGIONS; i++) {
+uint32_t orig, addr, val, size;
int ofs;
-uint32_t val, size ;
if (i == PCI_ROM_SLOT)
ofs = 0x30;
else
ofs = 0x10 + i * 4;
+orig = pci_config_readl(d, ofs);
pci_con
RE: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Sorry I made some mistakes concerning ROM BAR.
Although pci_default_write_config supports ROM BAR write emulation,
assigned_dev_pci_write_config does not invoke that function. The little patch
below shows where and when the function will be invoked.
Also initial mapping for ROM BAR is not setup in init_assigned_device. However,
I do not why they are not there.
diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
index 7a5..129d350 100644
--- a/qemu/hw/device-assignment.c
+++ b/qemu/hw/device-assignment.c
@@ -237,7 +237,7 @@ static void assigned_dev_pci_write_config(PCIDevice *d, uint
/* Continue to program the card */
}
-if ((address >= 0x10 && address <= 0x24) || address == 0x34 ||
+if ((address >= 0x10 && address <= 0x24) || address == 0x30 ||
address == 0x3c || address == 0x3d) {
/* used for update-mappings (BAR emulation) */
pci_default_write_config(d, address, val, len);
Best Regards
Haitao Shan
Avi Kivity wrote:
> Shan, Haitao wrote:
>> Hi, Avi,
>>
>> Option ROM already has its own BAR at 0x30h. I think the devices
>> assignment code now already handles this register.
>>
>
> Okay good.
>
>> Can I summary your proposals like the following: In guest BIOS, scan
>> all the pci devices (virtual) for existance of Option ROMs. Copy
>> them to available BIOS space in 0xC - 0xD. Execute the ROM
>> code at copied location.
>>
>
> Yes.
>
>> I don't understand why this makes differences compared to scanning
>> and copying Option ROMs in QEMU,
>
> If the ROM BAR is already handled (including registering the memory
> when the BAR is programmed -- I don't see that in the code), then
> there is no big advantage. It's closer to how real hardware works,
> but that's about it.
>
>> especially given that the VGA BIOS and etherboot ROM are also copied
>> to BIOS space in QEMU before they execute in rom_scan loop in guest
>> BIOS.
>>
>
> The VGA BIOS is typically present on the motherboard itself, at least
> on some configurations. You're right about etherboot.
>
> I'll apply the patch. Can you take a look at the ROM BAR?--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: PowerPC: Disarm old guest debug interface
On Wed, 2008-12-24 at 13:48 +0200, Avi Kivity wrote:
> Jan Kiszka wrote:
> > [Take this as a band-aid, I guess the PowerPC people can do better.]
> >
> > Until PowerPC is updated to the new guest debugging interface, we have
> > to remove the current implementation. This should also unbreak the
> > build.
> >
> >
>
> Hollis? Want this or a real fix?
I was trying to come up with a real fix, but unfortunately I don't have
time to reimplement and retest features like this.
kvm: ppc: remove debug support broken by KVM debug rewrite
After the rewrite of KVM's debug support, this code doesn't even build any
more.
Signed-off-by: Hollis Blanchard
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -118,11 +118,6 @@ struct kvm_arch {
struct kvm_vcpu_arch {
u32 host_stack;
u32 host_pid;
- u32 host_dbcr0;
- u32 host_dbcr1;
- u32 host_dbcr2;
- u32 host_iac[4];
- u32 host_msr;
u64 fpr[32];
ulong gpr[32];
@@ -200,10 +195,4 @@ struct kvm_vcpu_arch {
unsigned long pending_exceptions;
};
-struct kvm_guest_debug {
- int enabled;
- unsigned long bp[4];
- int singlestep;
-};
-
#endif /* __POWERPC_KVM_HOST_H__ */
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -71,9 +71,6 @@ extern int kvmppc_core_vcpu_translate(st
extern void kvmppc_core_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
extern void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu);
-extern void kvmppc_core_load_guest_debugstate(struct kvm_vcpu *vcpu);
-extern void kvmppc_core_load_host_debugstate(struct kvm_vcpu *vcpu);
-
extern void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu);
extern int kvmppc_core_pending_dec(struct kvm_vcpu *vcpu);
extern void kvmppc_core_queue_program(struct kvm_vcpu *vcpu);
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -28,72 +28,6 @@
#include "44x_tlb.h"
-/* Note: clearing MSR[DE] just means that the debug interrupt will not be
- * delivered *immediately*. Instead, it simply sets the appropriate DBSR bits.
- * If those DBSR bits are still set when MSR[DE] is re-enabled, the interrupt
- * will be delivered as an "imprecise debug event" (which is indicated by
- * DBSR[IDE].
- */
-static void kvm44x_disable_debug_interrupts(void)
-{
- mtmsr(mfmsr() & ~MSR_DE);
-}
-
-void kvmppc_core_load_host_debugstate(struct kvm_vcpu *vcpu)
-{
- kvm44x_disable_debug_interrupts();
-
- mtspr(SPRN_IAC1, vcpu->arch.host_iac[0]);
- mtspr(SPRN_IAC2, vcpu->arch.host_iac[1]);
- mtspr(SPRN_IAC3, vcpu->arch.host_iac[2]);
- mtspr(SPRN_IAC4, vcpu->arch.host_iac[3]);
- mtspr(SPRN_DBCR1, vcpu->arch.host_dbcr1);
- mtspr(SPRN_DBCR2, vcpu->arch.host_dbcr2);
- mtspr(SPRN_DBCR0, vcpu->arch.host_dbcr0);
- mtmsr(vcpu->arch.host_msr);
-}
-
-void kvmppc_core_load_guest_debugstate(struct kvm_vcpu *vcpu)
-{
- struct kvm_guest_debug *dbg = &vcpu->guest_debug;
- u32 dbcr0 = 0;
-
- vcpu->arch.host_msr = mfmsr();
- kvm44x_disable_debug_interrupts();
-
- /* Save host debug register state. */
- vcpu->arch.host_iac[0] = mfspr(SPRN_IAC1);
- vcpu->arch.host_iac[1] = mfspr(SPRN_IAC2);
- vcpu->arch.host_iac[2] = mfspr(SPRN_IAC3);
- vcpu->arch.host_iac[3] = mfspr(SPRN_IAC4);
- vcpu->arch.host_dbcr0 = mfspr(SPRN_DBCR0);
- vcpu->arch.host_dbcr1 = mfspr(SPRN_DBCR1);
- vcpu->arch.host_dbcr2 = mfspr(SPRN_DBCR2);
-
- /* set registers up for guest */
-
- if (dbg->bp[0]) {
- mtspr(SPRN_IAC1, dbg->bp[0]);
- dbcr0 |= DBCR0_IAC1 | DBCR0_IDM;
- }
- if (dbg->bp[1]) {
- mtspr(SPRN_IAC2, dbg->bp[1]);
- dbcr0 |= DBCR0_IAC2 | DBCR0_IDM;
- }
- if (dbg->bp[2]) {
- mtspr(SPRN_IAC3, dbg->bp[2]);
- dbcr0 |= DBCR0_IAC3 | DBCR0_IDM;
- }
- if (dbg->bp[3]) {
- mtspr(SPRN_IAC4, dbg->bp[3]);
- dbcr0 |= DBCR0_IAC4 | DBCR0_IDM;
- }
-
- mtspr(SPRN_DBCR0, dbcr0);
- mtspr(SPRN_DBCR1, 0);
- mtspr(SPRN_DBCR2, 0);
-}
-
void kvmppc_core_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
kvmppc_44x_tlb_load(vcpu);
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -216,36 +216,18 @@ void kvm_arch_vcpu_uninit(struct kvm_vcp
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
- if (vcpu->guest_debug.enabled)
- kvmppc_core_load_guest_debugstate(vcpu);
-
kvmppc_core_vcpu_load(vcpu, cpu);
}
void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
{
- if (vcpu->gues
Re: GPF on modprobe kvm-amd
This looks like that the BIOS did not load the same microcode patch in any individual core. So some cores have SVM disabled which triggers the #GP. I guess this is a BIOS bug. On Fri, Jan 02, 2009 at 11:45:12PM -0500, nuit...@melchior.nuitari.net wrote: > This is resolved, but since other people might have the problem I'll still > post what I > figured out. It seems like a strange corner case of memory allocation. > > I've upgraded to kernel 2.6.28 with kvm-82, but the problem kept persisting. > I've decided to > remove the evga 9800gt and suddenly it kvm-amd would load without any issue. > > I've decided to check the Asus website and sure enough there was a bios > update, I've > installed it then installed the evga card back it and since then everything > works (well > except rebooting but anyways). > > The bios update is 0603, it lists fix ups for some memory modules as an > improvement, so that > might be it. > > On Wed, 31 Dec 2008, Avi Kivity wrote: > > >Date: Wed, 31 Dec 2008 12:17:15 +0200 > >From: Avi Kivity > >To: nuit...@melchior.nuitari.net > >Cc: kvm@vger.kernel.org, Joerg Roedel > >Subject: Re: GPF on modprobe kvm-amd > >(adding cc) > > > >Joerg, all I can make of it is that svm is enabled on one cpu but not on the > >other. Can > >you help here? > > > >nuit...@melchior.nuitari.net wrote: > >> This is with kvm-81 > >> I'm getting a kernel panic when I modprobe kvm-amd > >> > >> It used to work until I had to use the CMOS jumper to boot. > >> The motherboard is an Asus M3N78 PRO > >> The CPU is an AMD Phenom 9950 Black Edition > >> > >> Here are the steps I've already tried: > >> - Checking that virtualization is enabled in the BIOS > >> - Updating the BIOS > >> - Restoring the defaults of the BIOS > >> - Downgrading the BIOS > >> - Trying various versions of kvm > >> - Trying various linux kernel versions > >> - Trying various vcore settings > >> - Enabling/Disabling Cool & Quiet and AMD C1E > >> - Tried a known good kernel and modules combo > >> - Interrupting the boot process to only have udev as a process, and > >> killing it. > >> - Not having any other modules loaded > >> > >> What I plan to try: > >> - Updating to 2.6.28 and kvm-82 > >> - Tranfering the nvram from an identical motherboard I own to the > >>problematic one, using /dev/nvram > >> > >> Here are the traces > >> [ 36.870419] general protection fault: [1] PREEMPT SMP > >> [ 36.870579] CPU 0 > >> [ 36.870667] Modules linked in: kvm_amd(+) kvm nvidia(P) snd_hda_intel > >> [ 36.870893] Pid: 0, comm: swapper Tainted: P 2.6.27-gentoo-r7 > >> #4 > >> [ 36.870955] RIP: 0010:[] [] > >> svm_hardware_enable+0x87/0xf0 [kvm_amd] > >> [ 36.871070] RSP: 0018:808d9f28 EFLAGS: 00010006 > >> [ 36.871130] RAX: 1d01 RBX: 0040 RCX: > >> c080 > >> [ 36.871193] RDX: RSI: 88021c41c9c0 RDI: > >> > >> [ 36.871255] RBP: 808d9f48 R08: R09: > >> > >> [ 36.871317] R10: R11: 80869e88 R12: > >> 88021e843cc0 > >> [ 36.871379] R13: 88021e843ce8 R14: R15: > >> > >> [ 36.871413] FS: 7fbabbbec6f0() GS:80863340() > >> knlGS: > >> [ 36.871413] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > >> [ 36.871413] CR2: 7fbabbc22000 CR3: 00201000 CR4: > >> 06e0 > >> [ 36.871413] DR0: DR1: DR2: > >> > >> [ 36.871413] DR3: DR6: 0ff0 DR7: > >> 0400 > >> [ 36.871413] Process swapper (pid: 0, threadinfo 80868000, task > >> 80808340) > >> [ 36.871413] Stack: 88002803607f 8025 880028038d20 > >> 0011 > >> [ 36.871413] 808d9f58 a07c002e 808d9f68 > >> a07bceaf > >> [ 36.871413] 808d9f98 8026515b 0011 > >> 808ae500 > >> [ 36.871413] Call Trace: > >> [ 36.871413][] ? > >> tick_broadcast_oneshot_control+0xff/0x130 > >> [ 36.871413] [] kvm_arch_hardware_enable+0xe/0x10 > >> [kvm] > >> [ 36.871413] [] hardware_enable+0x2f/0x40 [kvm] > >> [ 36.871413] [] > >> generic_smp_call_function_interrupt+0x6b/0x160 > >> [ 36.871413] [] smp_call_function_interrupt+0x19/0x30 > >> [ 36.871413] [] call_function_interrupt+0x66/0x70 > >> [ 36.871413][] ? default_idle+0x42/0x50 > >> [ 36.871413] [] ? c1e_idle+0x38/0x100 > >> [ 36.871413] [] ? > >> atomic_notifier_call_chain+0x11/0x20 > >> [ 36.871413] [] ? cpu_idle+0x56/0xc0 > >> [ 36.871413] [] ? rest_init+0x86/0x90 > >> [ 36.871413] > >> [ 36.871413] > >> [ 36.871413] Code: 46 10 0f 01 45 e0 48 8b 45 e2 b9 80 00 00 c0 48 83 c0 > >> 40 48 89 46 18 0f 32 48 c1 e2 20 89 c0 48 09 c2 89 d0 48 c1 ea 20 80 cc 10 > >> <0f> 30 48 ba 00 00 00 00 00 1e 00 00 48 03 56 2
Re: lsi_scsi: error: Bad Status move errors with kvm-79
On Thu, Jan 01, 2009 at 05:34:33PM +0200, Anssi Kolehmainen wrote: > Tried kvm-82 (2.6.28-rc7 kernel, kvm-82 modules) today and the same > bug still exists. I thought everything was working somewhat fine but > then Windows decided to shoot with shotgun at its own system files and I > got to spend the day recovering and then rebuilding the vm :) > > I'll setup another computer and see whether I can reproduce that on another > system. Well, this time on a brand new PC with 2.6.28, KVM-82. Everything started out working fine and I thought I couldn't get any errors. First Oracle DB installation resulted only in few "windows detected controller error" messages in event log (but those don't cause any problems). After that Weblogic installation caused windows to BSOD (but no Bad Status move error). After reboot I tried copying the installation file to guest drive and that caused 4 Bad Status moves and BSOD... Tried without kvm modules and everything worked fine (except being rather slow). Did the same thing with kvm modules loaded and it hit the error. Could this be some kind of timing issue? http://kelvin.aketzu.net/kvm-2sec.log.bz2 contains about two last seconds of debugging output (with DEBUG_LSI and DEBUG_LSI_REG). Added second.microsecond timestamps to keep better track of what is going on. At the moment of crash windows was writing to disk about 10mb/s (copying file over 100mbps lan). -- Anssi Kolehmainen anssi.kolehmai...@iki.fi 040-5085390 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
