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

Avi Kivity
2007-09-09T12:55:07Z

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