Anthony Liguori wrote: > I like this idea but I have some suggestions about the general approach. > I think instead of defining another machine type, it would be better to > just have a command line option like -cpuid that took a comma separate > string of features with "all" meaning all features that the host has.
I like the idea of a flag to enable specific features, but I think "host" would be a better name for the features of the host. "all" seems more appropriate to enable all the features the emulator can support, which can include features which the host does not support itself. If it's a comma separated list, it would be good to be able to write something like this example, which selects all the host features but then overrides it by disabling the psn feature: -cpuid host,-psn Is it intended that these flags will also control the actual features which Qemu allows or emulates, or only what cpuid reports to the guest? > I also think it would be nicer to use cpuid() directly instead of > attempting to parse /proc/cpuinfo. Occasionally the features in /proc/cpuinfo differ from what the cpuid instruction reports. They are CPU bug workarounds (features disabled intentionally even though cpuid reports them), CPU features which aren't properly reported (enabled intentionally in cpuinfo), and boot flag requests (features disabled due to request from the boot command line). I'm inclined to think the feature list in /proc/cpuinfo is more appropriate, for choosing the best set of host features to make available to guests. It's unlikely that Qemu itself will duplicate the logic of known workarounds for specific, obscure, buggy host CPUs. There is also /dev/cpu/%d/cpuinfo (for %d = 0, 1, etc.) on some Linux distros, I think. -- Jamie
