LinuxQuestions.org - [SOLVED] Building SlackBuilds KVM doesn't work, 2.6.35.4 kernel

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Building SlackBuilds KVM doesn't work, 2.6.35.4 kernel (https://www.linuxquestions.org/questions/slackware-14/building-slackbuilds-kvm-doesnt-work-2-6-35-4-kernel-835647/)

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.

Code:

root@slackware:# modinfo kvm

filename:      /lib/modules/2.6.33.4/kernel/arch/x86/kvm/kvm.ko

license:        GPL

author:        Qumranet

depends:        

vermagic:      2.6.33.4 SMP mod_unload 

parm:          oos_shadow:bool

parm:          ignore_msrs:bool

Code:

root@slackware:# modinfo kvm-amd

filename:      /lib/modules/2.6.33.4/kernel/arch/x86/kvm/kvm-amd.ko

license:        GPL

author:        Qumranet

depends:        kvm

vermagic:      2.6.33.4 SMP mod_unload 

parm:          npt:int

parm:          nested:int

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

Code:

qemu-img info <disk image file>

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.

Quote:

Originally Posted by Ramurd (Post 4119028)

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.

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.)

Quote:

Originally Posted by Ramurd (Post 4119028)

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

Code:

qemu-img info <disk image file>

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

Quote:

Originally Posted by Ramurd (Post 4119028)

For example, it stops while booting the Slackware DVD.
Attachment 4782

Quote:

Originally Posted by Chuck56 (Post 4119051)

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

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

Quote:

Originally Posted by Squall90 (Post 4119548)

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.

Quote:

root@tux:/home/christian# modinfo kvm
filename: /lib/modules/2.6.35.4-smp/kernel/arch/x86/kvm/kvm.ko
license: GPL
author: Qumranet
depends:
vermagic: 2.6.35.4-smp SMP mod_unload K8
parm: oos_shadow:bool
parm: ignore_msrs:bool
root@tux:/home/christian# modinfo kvm-amd
filename: /lib/modules/2.6.35.4-smp/kernel/arch/x86/kvm/kvm-amd.ko
license: GPL
author: Qumranet
depends: kvm
vermagic: 2.6.35.4-smp SMP mod_unload K8
parm: npt:int
parm: nested:int

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

Quote:

Originally Posted by Squall90 (Post 4119577)

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.

Quote:

Originally Posted by Chuck56 (Post 4119583)

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?

Quote:

Originally Posted by Squall90 (Post 4119790)

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...

Code:

/usr/share/mkinitrd/mkinitrd_command_generator.sh

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):

Code:

qemu-system-x86_64 -monitor stdio -vga vmware -cpu qemu64 -soundhw all -m 2048 -localtime -drive file=./Qemu/slackware13.1.img,if=ide -cdrom ./Downloads/slackware-13.1-install-dvd.iso -name "virtual_slack" -enable-kvm

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.

Quote:

Originally Posted by Squall90 (Post 4115860)

No, it's the only message.

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.