Squall90,

With all the package installing and uninstalling you've gone through, which version of kvm and kvm-amd are you running? Here's mine from a stock 13.1 x86_64 generic kernel.

Just my 2 cents worth of comments:

If kvm-amd is not running, you probably don't have virtualization enabled in your BIOS. No need -normally- to update the BIOS, but you'll have to enter the BIOS to enable it. Normally this switched off. It's just a toggle on/off thing, so nothing major and you'll not notice anything else that would stop working or so.

Second: I noticed a stiff drop on performance recently due to using the wrong disk image type... I used qcow instead of qcow2; Which disk image type do you use? (please provide the output of Could you also provide the outcome of a short investigation on where the performance comes to a grinding halt? Is there much wait-io (which would point towards disk issues), is there enough memory allocated, or is your virtual machine swapping? Performance tools like sar and top will help much here.

What I was getting at with my last post regarding the modules was this. If the OP installed the KVM package (which was reported earlier in the thread) and did not remove the KVM package or did not run "depmod -a" after removing the KVM package then that could be part of the slowness problem. The OP could be running the older KVM modules and not the current kernel modules. There hasn't been a reply from the OP so it must not be an issue anymore.

kvm is running, otherwise qemu would print some errors. I looked for some virtualization options in the BIOS but I couldn't find any. (And, as I already said, I'll never ever update a BIOS if it's not 100% required.)

I'm using raw format created with `dd'.

For example, it stops while booting the Slackware DVD.
qemu-kvm.png

I didn't run "depmod -a" but now, after I run it, nothing changed.

Use a different -cpu option. There's a bug in qemu/kvm and AMD CPUs.

qemu-system-x86_64 -cpu core2duo $YOUR-OTHER-OPTIONS

1 members found this post helpful.

If I do not start kvm-amd module qemu works fine -- not fast, but it works. If I start the module, I only come this far: Attachment 4782

Makes me think that there is a mismatch between the kvm modules and the userspace programs. When you checked the kvm modules using the modinfo command did the output match what I listed earlier? I'm wondering if you have an older batch of modules that don't work well with the newer userspace tools.

This kernel is almost a standard huge-smp kernel, just newer and I deactivated some Intel stuff -- I only need snd_hda_intel.

Have you tried to run with a generic kernel and an initrd? Running a recompiled huge kernel may not be helping the situation. At this point I'm out of ideas.

It is not re-compiled. I downloaded the current version of the kernel from kernel.org and then I run "make oldconfig" with the standard huge-smp config.

However, I'll try the generic kernel later ~ now I'm about to go to bed.

Do I have to regard something while building the initrd except for the drivers for my partitions?

Not for kvm but you know your setup best. I usually just run and copy the output from...
You have to run lilo afterward but I think it reminds you.

Raw images should work good, used them in the past, but went for the qcow2 format. Matter of taste kind of stuff

It amazes me that your VM comes to a grinding halt after loading the kernel but before the boot scripts are ran;

If you started your VM like this (with or without the running module):
NB: I allocated a different cpu, vga card and memory is exactly 2G instead of 1 MB less (could this cause an issue?), gave the machine a name and requested to use kvm stuff. in fact, I've just been a bit more precise in the definition of the virtual machine

Does this give a different performance?
If it does: determining which parameter makes the difference will be interesting; try to tweak above command line removing / altering parameters according to the command line you used before, one parameter at a time.

If it doesn't, look at the host: any stress to determine there? (sar / top for memory issues, io waits etc)

Hope we get the solution.

I traced through the qemu-kvm code, and found there are only two possibilities that can cause that exact output. 1) There is an error with an ioctl for KVM_GET_MSR_INDEX_LIST or 2) setting up irq routing. If you could trace the code, you can find an exact answer to your problem to go on if you talk to the kvm people.

I would definitely try to make sure your userspace is set up correctly, and also that you did not accidentally use the wrong kvm headers.

Hmm.. somehow, the standard 13.1 huge smp kernel works. I mean, kvm seam to work with it.