Re: [Qemu-devel] Semantics of "-cpu host" (was Re: [PATCH 2/2] Expose tsc deadline timer cpuid to guest)

[Andre Przywara]

On 05/07/2012 08:21 PM, Eduardo Habkost wrote:
> Andre? Are you able to help to answer the question below?

Sorry for the delay, the easy answers first:

> I would like to clarify what's the expected behavior of "-cpu host" to
> be able to continue working on it.

The purpose of -cpu host is to let guests use ISA features that the host 
CPU provides. Those would not need any KVM/QEMU intervention, because 
they work out of the box. Things like AES or SSE4.2, which are used by 
Linux and glibc, for instance. Users would expect those to be usable, 
and actually we only need to set the bits and are done.

A second goal is to get rid of the awkward and artificial 
family/model/stepping settings and just let the guest see the actual CPU 
model. This has some strings attached, though, but other virtualization 
solution do it the same way and they can cope with it.

A third thing currently not really addressed are the more informational 
bits like cache size and organization and TLB layout. Those are 
properties of the (core) CPU (except shared L3, cache maybe) and apply 
to guests as well. I don't see any reason why this should not be exposed 
to the guest. From the top of my head I don't know any prominent user 
(just glibc reading the cache size, but not really using it), but I 
guess there are applications which benefit from it.

What clearly is not the intention of -cpu host is to provide access to 
every feature a certain CPU model provides. So things which require 
emulation or hypervisor intervention are not in the primary use case. 
That does not mean that they don't need to implemented, but that was not 
the purpose of -cpu host and they should be handled independently.

Regards,
Andre.

I believe the code will need to be
> fixed on either case, but first we need to figure out what are the
> expectations/requirements, to know _which_ changes will be needed.
>
>
> On Tue, Apr 24, 2012 at 02:19:25PM -0300, Eduardo Habkost wrote:
> > (CCing Andre Przywara, in case he can help to clarify what's the
> > expected meaning of "-cpu host")
> [...]
> > I am not sure I understand what you are proposing. Let me explain the
> > use case I am thinking about:
> >
> > - Feature FOO is of type (A) (e.g. just a new instruction set that
> >    doesn't require additional userspace support)
> > - User has a Qemu vesion that doesn't know anything about feature FOO
> > - User gets a new CPU that supports feature FOO
> > - User gets a new kernel that supports feature FOO (i.e. has FOO in
> >    GET_SUPPORTED_CPUID)
> > - User does _not_ upgrade Qemu.
> > - User expects to get feature FOO enabled if using "-cpu host", without
> >    upgrading Qemu.
> >
> > The problem here is: to support the above use-case, userspace need a
> > probing mechanism that can differentiate _new_ (previously unknown)
> > features that are in group (A) (safe to blindly enable) from features
> > that are in group (B) (that can't be enabled without an userspace
> > upgrade).
> >
> > In short, it becomes a problem if we consider the following case:
> >
> > - Feature BAR is of type (B) (it can't be enabled without extra
> >    userspace support)
> > - User has a Qemu version that doesn't know anything about feature BAR
> > - User gets a new CPU that supports feature BAR
> > - User gets a new kernel that supports feature BAR (i.e. has BAR in
> >    GET_SUPPORTED_CPUID)
> > - User does _not_ upgrade Qemu.
> > - User simply shouldn't get feature BAR enabled, even if using "-cpu
> >    host", otherwise Qemu would break.
> >
> > If userspace always limited itself to features it knows about, it would
> > be really easy to implement the feature without any new probing
> > mechanism from the kernel. But that's not how I think users expect "-cpu
> > host" to work. Maybe I am wrong, I don't know. I am CCing Andre, who
> > introduced the "-cpu host" feature, in case he can explain what's the
> > expected semantics on the cases above.


--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany