Bug 707523

+++ This bug was initially created as a clone of Bug #647862 +++

Description of problem:
virt-what is silent inside a 32-bit guest run on top of Fedora 13 64-bit kvm

Version-Release number of selected component (if applicable):
hypervisor: qemu-kvm-0.12.5-1.fc13.x86_64
VM: 

How reproducible:


Steps to Reproduce:
1. running 64-bit F13 host
2. start 32-bit F13 VM
3. virt-what
4. /usr/libexec/virt-what-cpuid-helper
5. cat /proc/cpuinfo
  
Actual results:
$ virt-what
$ /usr/libexec/virt-what-cpuid-helper
KVMKVMKVM
$ cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 3
model name	: Pentium II (Klamath)
stepping	: 3
cpu MHz		: 2792.776
cache size	: 4096 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 4
wp		: yes
flags		: fpu de pse tsc msr pae mce cx8 apic pge cmov mmx fxsr sse sse2 up pni hypervisor
bogomips	: 5585.55
clflush size	: 32
cache_alignment	: 32
address sizes	: 36 bits physical, 32 bits virtual
power management:


Expected results:
virt-what should output kvm and/or qemu

Additional info:
Let me know if you need any more details about the XML that libvirt uses to describe my VM, or any other tests I can help run.

--- Additional comment from eblake on 2010-10-29 14:09:53 EDT ---

VM: virt-what-1.3-3.fc13.i686

--- Additional comment from rjones on 2010-10-29 15:09:21 EDT ---

Eric, are you running virt-what as root?

Do you have a /proc/xen directory in the guest?  (Not exactly
sure why it would be there, but please check).

What is the output of dmidecode?

I happen to have a F13 32 bit guest on top of F14 x86_64 host,
which is very nearly the same as you describe.

# virt-what 
kvm
# /usr/libexec/virt-what-cpuid-helper 
KVMKVMKVM

So it works for me.

--- Additional comment from rjones on 2010-10-29 15:10:29 EDT ---

Ah, hang about ...

I see what's happening, and it's a bug.  I assume that you are
passing the -cpu flag to qemu (or maybe via libvirt)?

--- Additional comment from eblake on 2010-10-29 15:33:35 EDT ---

libvirt is probably passing the -cpu flag.  Let me check...

LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc-0.11 -cpu qemu32 -enable-kvm -m 768 -smp 1,sockets=1,cores=1,threads=1 -name fedora_13-initial -uuid 24ab99db-bf50-085d-d3e5-7528243ae9b0 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/fedora_13-initial.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/fedora_13-clone.img,if=none,id=drive-virtio-disk0,boot=on,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:65:82:9e,bus=pci.0,addr=0x5 -net tap,fd=48,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -k en-us -vga cirrus -device ES1370,id=sound0,bus=pci.0,addr=0x6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 
char device redirected to /dev/pts/4

Yep - -cpu qemu32.

--- Additional comment from rjones on 2010-10-29 16:08:12 EDT ---

Created attachment 456553 [details]
Patch to ignore /proc/cpuinfo in QEMU/KVM test

Suggested patch.

--- Additional comment from eblake on 2010-10-29 16:16:22 EDT ---

Patch works for my testing of kvm guests.

--- Additional comment from rjones on 2010-10-30 02:20:50 EDT ---

Comment on attachment 456553 [details]
Patch to ignore /proc/cpuinfo in QEMU/KVM test

This patch is wrong.  Baremetal would appear as "qemu".  We need to test dmidecode output as well.

--- Additional comment from rjones on 2011-05-24 13:36:54 EDT ---

Bump this up to Rawhide, not fixed upstream.

--- Additional comment from pbonzini on 2011-05-25 04:28:31 EDT ---

dmidecode output can be changed as well.  It seems better to provide custom CPUID leaves (like KVMKVMKVM) in non-kvm QEMU, and in the meanwhile use /proc/cpuinfo to detect non-kvm QEMU.

--- Additional comment from rjones on 2011-05-25 05:34:36 EDT ---

*** Bug 707352 has been marked as a duplicate of this bug. ***

--- Additional comment from rjones on 2011-05-25 05:44:04 EDT ---

A simple reproducer for this is to edit the libvirt
configuration for a guest, adding an explicit CPU model.
eg for a 64 bit guest you could add:

<domain>
  <!-- ... -->
  <cpu match='exact'>
    <model>core2duo</model>
    <vendor>Intel</vendor>
  </cpu>

The effect of this is to add the following flag to the
qemu command line:

-cpu core2duo

When the guest has been booted, you will see inside the
guest, in /proc/cpuinfo:

$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz
[etc]

Note that the "QEMU" string is no longer present in /proc/cpuinfo.

virt-what now fails to detect that this is QEMU, producing no output.

I'll just make a simple patch for this.  Paolo in comment 9 is
correct that a general fix is going to involve fixing qemu (wish
me luck with that), but we can work around this easily by detecting
the strings in dmidecode for now.

--- Additional comment from rjones on 2011-05-25 06:17:44 EDT ---

I pushed the following patch upstream which fixes the
problem for me:

http://git.annexia.org/?p=virt-what.git;a=commitdiff;h=441ce9d9ecf9edf0f325c280451ba69dc160882e

Tested on KVM with explicit -cpu core2duo option as
described in the previous comment.

However it won't work for (non-accelerated) qemu with
the explicit -cpu option, although that should be a
rare case.