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

[Avi Kivity <avi@qumranet.com>]

Jamie Lokier wrote:
> Avi Kivity wrote:
>   
>> Well, the guest will invoke its own workaround logic to disable buggy 
>> features, so I see no issue here.
>>     
>
> The guest can only do this if it has exactly the correct id
> information for the host processor (e.g. "This is an Intel Pentium Pro
> model XXX"), not just the list of safe to use CPU features.
>
> This isn't possible in a virtualisation cluster of many different CPUs
> where the point is to advertise the common set of cpuid features, and
> for the guest images to be able to migrate between different CPUs in
> the cluster.
>   

Well, for a cluster the management software will coordinate all cpuid 
features, perhaps taking into account features removed by the host 
kernel. "-cpu host" is for the gentoo user who wants to enable all the 
nice cpu flags.

> Then, the common cpuid features must be found by combining the
> /proc/cpuinfo from each node in the cluster.  But I guess that's
> separate from the part of Qemu we are discussing; it would be done by
> another program, preparing the -cpuid argument.
>   

Exactly.

> But sometimes it's good to run a simple guest (e.g. someone's pet OS
> project, or anything written for Intel only which was more common in
> the past) which doesn't have all the detailed obscure workarounds of
> something like Linux, but still be able to take advantage of the
> workarounds and obscure knowledge in the host.
>
> The alternative is Qemu itself may end up having to have some of these
> obscure workarounds :/
>
> For example, the sysenter instruction is advertised on early Pentium
> Pros, but it doesn't work.  Linux removes it from the features in
> /proc/cpuinfo, and doesn't use it.  But some guests simply don't get
> that obscure, and use it if cpuid advertises it.  Of course, they
> don't work on a _real_ early Pentium Pro.  But it would be nice if
> they did work without anything special when run in Qemu on such a
> host.  That's an old chip which I happen to know about, but I'm sure
> there are more modern similar issues.
>
> Perhaps there could be two options then: "-cpuid host-os", and "-cpuid
> host-cpuid".  I would suggest making "host" an alias for "host-os",
> but I wouldn't object if it were an alias for "host-cpuid" or didn't
> exist at all, so you had to choose one.
>   

Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu 
host-os' on the first bug report?  I have a feeling we won't ever see it.


-- 
error compiling committee.c: too many arguments to function