Jamie Lokier wrote: > 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 >
Yes, 'host' and 'all' make more sense the way you describe them from the emulator perspective. > 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? > > The cpuid features are sufficient (and there's precedent -- some mobile intel processors support pae but don't report it). >> 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. > Well, the guest will invoke its own workaround logic to disable buggy features, so I see no issue here. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
