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

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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/