On 10/13/2011 02:51 AM, Jorge Lucangeli Obes wrote: > On Wed, Oct 12, 2011 at 3:52 PM, Jorge Lucangeli Obes > <jorgelo@xxxxxxxxxxxx> wrote: > > On Wed, Oct 12, 2011 at 12:55 PM, Alexander Graf <agraf@xxxxxxx> wrote: > >> > >> On 12.10.2011, at 20:49, Jorge Lucangeli Obes wrote: > >> > >>> Hi all, > >>> > >>> I'm working on Chromium OS development. We have a pretty elaborate > >>> chroot inside of which we carry out all development. We use KVM to > >>> launch Chromium OS builds inside a VM for testing. Turns out that for > >>> some reason, when QEMU is launched from inside the chroot, KVM itself > >>> seems not to be used. The VM is extremely slow. > >>> > >>> Is this known/expected? QEMU is installed inside the chroot, the KVM > >>> modules are loaded, the /dev/kvm device is present and accesible. Any > >>> ideas on how to debug this? > >> > >> The first obvious idea I'd have here would be to strace the qemu process and check what happens when it opens /dev/kvm :) > > Resending since original attachment was too large. > > > That's what I thought. I did a test run under strace. I'm attaching > > the list of syscalls from the call to 'open(/dev/kvm)' to the first > > successful 'ioctl(KVM_RUN)'. /dev/kvm seems to be opened correctly, a > > VCPU is created, and then that VCPU is used with KVM_RUN. After the > > first call to 'ioctl(KVM_RUN)', there are long lists of more KVM_RUN > > calls, separated by brief groups of other calls. So, IIUC, KVM seems > > to be used, and seems to be "working", but the VM is one order of > > magnitude slower anyways. > > > > Any ideas? > What do top/vmstat/kvm_stat say? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
