On 09.05.2012, at 10:14, Gleb Natapov <gleb@xxxxxxxxxx> wrote: > On Wed, May 09, 2012 at 12:07:04AM +0200, Alexander Graf wrote: >> >> On 08.05.2012, at 22:14, Eduardo Habkost wrote: >> >>> On Tue, May 08, 2012 at 02:58:11AM +0200, Alexander Graf wrote: >>>> On 07.05.2012, at 20:21, Eduardo Habkost wrote: >>>> >>>>> >>>>> 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. >>>> >>>> Can you think of any feature that'd go into category B? >>> >>> - TSC-deadline: can't be enabled unless userspace takes care to enable >>> the in-kernel irqchip. >> >> The kernel can check if in-kernel irqchip has it enabled and otherwise mask it out, no? >> > How kernel should know that userspace does not emulate it? You have to enable the in-kernel apic to use it, at which point the kernel knows it's in use, right? > >>> - x2apic: ditto. >> >> Same here. For user space irqchip the kernel side doesn't care. If in-kernel APIC is enabled, check for its capabilities. >> > Same here. > > Well, technically both of those features can't be implemented in > userspace right now since MSRs are terminated in the kernel, but I Doesn't sound like the greatest design - unless you deprecate the non-in-kernel apic case. > wouldn't make it into ABI. > > > -- > Gleb. -- 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
