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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
