Andre? Are you able to help to answer the question below? I would like to clarify what's the expected behavior of "-cpu host" to be able to continue working on it. 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. > -- Eduardo -- 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
