Should emulate /proc/cpuinfo

Adding an upstream task.

Anthony will be able to tell us if this is possible, and why /proc/cpuinfo is structured the way it currently is in QEMU.

I don't know what is meant by "should emulate /proc/cpuinfo". Can you please be more specific?

NB, the default CPU that is exposed is a generic one which allows for maximum portability with respect to live migration. You can use the '-cpu host' option to expose the underlying host CPU although that decreases migration portability.

thats exactly the opposite of what we need when emulating a foreign architecture :)
in case of running qemu-user you want the ability to emulate the foreign architecture in a generic way.

i.e. we build a static flavour of qemu-user for armel in ubuntu that integrates with the binfmt handler of the kernel to allow you run armel chroots on x86 systems.
certain packages or build systems parse /proc/cpuinfo to find out the arch they are running on and its capabilities.

i think loic wasnt specific enough in his initial description, if we run qemu-system there is indeed a generic cpu, what we would like is the opportunity to emulate this same cpu in qemu-user through i.e. some kind of overlay for the cpuinfo file if proc is mounted in a chroot.

This is about qemu-arm as in the syscall emulation version of qemu; /proc/cpuinfo is simply the host's /proc/cpuinfo, but when one emulates e.g. an ARM program which reads /proc/cpuinfo to find out on which architecture it's running (or which features the CPU has), it wont find the relevant info.

qemu in syscall emulation should intercept open()s on /proc/cpuinfo and return contents matching the emulated CPU.

NB: qemu in machine emulation mode doesn't have this problem obviously, since an emulated kernel is returning the /proc/cpuinfo for the virtual hardware it's running on.

Is there a way to tag qemu-kvm bugs related to qemu syscall versus machine emulation?

To your last question, Loic, tags, no, QEMU upstream hasn't yet really made use of tags. Feel free to add one ;-)

Tagged "linux-user" as I think that describes well what codebase I mean.

If you're chroot'ing anyway, then you should have privileged access. You could probably do this entirely in userspace, without even specially intercepting the syscalls. When you set up the chroot, just get a copy of how you want cpuinfo to look, and bind mount it on top of the existing cpuinfo file:

root@nimitz:~# egrep cache.size\|^processor /proc/cpuinfo
processor : 0
cache size : 4096 KB
processor : 1
cache size : 4096 KB
root@nimitz:~# cat /proc/cpuinfo | perl -pe 's/4096 KB/8192 KB/g' > cpuinfo.lie
root@nimitz:~# mount --bind cpuinfo.lie /proc/cpuinfo
root@nimitz:~# egrep cache.size\|^processor /proc/cpuinfo
processor : 0
cache size : 8192 KB
processor : 1
cache size : 8192 KB

Would that work?

I think the preferred way to do this is just to create a /proc/cpuinfo file within the root file system. It's impossible for qemu to know which file is /proc/cpuinfo because you can technically mount procfs anywhere.