[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [kvm-devel] [Qemu-devel] Re: expose host CPU features to guests

From: Avi Kivity
Subject: Re: [kvm-devel] [Qemu-devel] Re: expose host CPU features to guests
Date: Sun, 09 Sep 2007 10:51:52 +0300
User-agent: Thunderbird (X11/20070419)

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]