[Qemu-devel] QOM: stability expectations of introspectable class_init data
Hi, This is an attempt to summarize my main question from the thread: Re: [Qemu-devel] [RFC v5] target-i386: Slim conversion to X86CPU subclasses + KVM subclasses My main unanswered question is about the stability expectations of the introspectable class data (especially property defaults). I am assuming and expecting that the introspectable QOM class data (especially property defaults) should simply reflect capabilities/behavior of the QEMU binary being queried, and would not change depending on the environment QEMU is running (host hardware and host kernel). This way, other components can use class introspection to probe for QEMU capabilities/behavior, and safely expect that the QEMU binary being queried will always have those capabilities/behavior. What Igor is proposing is to break my assumption, and make the default value of the vendor property on the X86CPU subclasses be different depending on the host CPU where QEMU is running. My question is: is that really OK? In another case, we are considering making other properties of a X86CPU subclass have different defaults depending on the capabilities of the host kernel (the host CPU class will have different feature property defaults depending on the capabilities reported by GET_SUPPORTED_CPUID). Would that be OK, too? -- Eduardo
Re: [Qemu-devel] QOM: stability expectations of introspectable class_init data
On Fri, 15 Feb 2013 10:50:16 -0200 Eduardo Habkost ehabk...@redhat.com wrote: Hi, This is an attempt to summarize my main question from the thread: Re: [Qemu-devel] [RFC v5] target-i386: Slim conversion to X86CPU subclasses + KVM subclasses My main unanswered question is about the stability expectations of the introspectable class data (especially property defaults). I am assuming and expecting that the introspectable QOM class data (especially property defaults) should simply reflect capabilities/behavior of the QEMU binary being queried, and would not change depending on the environment QEMU is running (host hardware and host kernel). This way, other components can use class introspection to probe for QEMU capabilities/behavior, and safely expect that the QEMU binary being queried will always have those capabilities/behavior. What Igor is proposing is to break my assumption, and make the default value of the vendor property on the X86CPU subclasses be different depending on the host CPU where QEMU is running. i.e. reflecting actual value of CPUID.vendor of the host. alternative proposed by Eduardo: is to abstract default value of vendor property to host string. My question is: is that really OK? In another case, we are considering making other properties of a X86CPU subclass have different defaults depending on the capabilities of the host kernel (the host CPU class will have different feature property defaults depending on the capabilities reported by GET_SUPPORTED_CPUID). Would that be OK, too?
Re: [Qemu-devel] QOM: stability expectations of introspectable class_init data
On Fri, Feb 15, 2013 at 02:35:26PM +0100, Igor Mammedov wrote: On Fri, 15 Feb 2013 10:50:16 -0200 Eduardo Habkost ehabk...@redhat.com wrote: Hi, This is an attempt to summarize my main question from the thread: Re: [Qemu-devel] [RFC v5] target-i386: Slim conversion to X86CPU subclasses + KVM subclasses My main unanswered question is about the stability expectations of the introspectable class data (especially property defaults). I am assuming and expecting that the introspectable QOM class data (especially property defaults) should simply reflect capabilities/behavior of the QEMU binary being queried, and would not change depending on the environment QEMU is running (host hardware and host kernel). This way, other components can use class introspection to probe for QEMU capabilities/behavior, and safely expect that the QEMU binary being queried will always have those capabilities/behavior. What Igor is proposing is to break my assumption, and make the default value of the vendor property on the X86CPU subclasses be different depending on the host CPU where QEMU is running. i.e. reflecting actual value of CPUID.vendor of the host. alternative proposed by Eduardo: is to abstract default value of vendor property to host string. Exactly. Just to be clear: the actual CPUID vendor exposed to the guest _will_ change depending on the host CPU because we need to keep the behavior compatible with previous QEMU versions (that already do that). My question is about how to model that behavior in QOM. My question is: is that really OK? In another case, we are considering making other properties of a X86CPU subclass have different defaults depending on the capabilities of the host kernel (the host CPU class will have different feature property defaults depending on the capabilities reported by GET_SUPPORTED_CPUID). Would that be OK, too? -- Eduardo
Re: [Qemu-devel] QOM: stability expectations of introspectable class_init data
Eduardo Habkost ehabk...@redhat.com writes: Hi, This is an attempt to summarize my main question from the thread: Re: [Qemu-devel] [RFC v5] target-i386: Slim conversion to X86CPU subclasses + KVM subclasses My main unanswered question is about the stability expectations of the introspectable class data (especially property defaults). I am assuming and expecting that the introspectable QOM class data (especially property defaults) should simply reflect capabilities/behavior of the QEMU binary being queried, and would not change depending on the environment QEMU is running (host hardware and host kernel). This way, other components can use class introspection to probe for QEMU capabilities/behavior, and safely expect that the QEMU binary being queried will always have those capabilities/behavior. What Igor is proposing is to break my assumption, and make the default value of the vendor property on the X86CPU subclasses be different depending on the host CPU where QEMU is running. My question is: is that really OK? The rules are: 1) We can add and remove types but we can never change the semantics of the type. If the 'serial' device is an ISA UART16650A, it must stay that. 2) We can add and remove properties but never change their semantics. Removing properties should be done in a limited fashion of course. 3) Whenever using a '-M' parameter, a given command line syntax must produce an identical system from the guest's point of view on a newer QEMU version when all other things are equal. So generally speaking, we can, and do, change default values but we also have to add compat properties to make sure of (3). CPU vendor is a special case. It's not reasonable to expose a general vendor string when using KVM. Hence the 'all other things are equal' clause. In another case, we are considering making other properties of a X86CPU subclass have different defaults depending on the capabilities of the host kernel (the host CPU class will have different feature property defaults depending on the capabilities reported by GET_SUPPORTED_CPUID). Would that be OK, too? Given 'all other things are equal', yes, it would be. FWIW, I agree with the suggestion elsewhere in the thread that instead of changing default values, an auto detect value is a more user friendly way of having this behavior. Regards, Anthony Liguori -- Eduardo
Re: [Qemu-devel] QOM: stability expectations of introspectable class_init data
On Fri, Feb 15, 2013 at 08:22:31AM -0600, Anthony Liguori wrote: Eduardo Habkost ehabk...@redhat.com writes: Hi, This is an attempt to summarize my main question from the thread: Re: [Qemu-devel] [RFC v5] target-i386: Slim conversion to X86CPU subclasses + KVM subclasses My main unanswered question is about the stability expectations of the introspectable class data (especially property defaults). I am assuming and expecting that the introspectable QOM class data (especially property defaults) should simply reflect capabilities/behavior of the QEMU binary being queried, and would not change depending on the environment QEMU is running (host hardware and host kernel). This way, other components can use class introspection to probe for QEMU capabilities/behavior, and safely expect that the QEMU binary being queried will always have those capabilities/behavior. What Igor is proposing is to break my assumption, and make the default value of the vendor property on the X86CPU subclasses be different depending on the host CPU where QEMU is running. My question is: is that really OK? The rules are: 1) We can add and remove types but we can never change the semantics of the type. If the 'serial' device is an ISA UART16650A, it must stay that. 2) We can add and remove properties but never change their semantics. Removing properties should be done in a limited fashion of course. 3) Whenever using a '-M' parameter, a given command line syntax must produce an identical system from the guest's point of view on a newer QEMU version when all other things are equal. So generally speaking, we can, and do, change default values but we also have to add compat properties to make sure of (3). OK, thanks for the explanation. CPU vendor is a special case. It's not reasonable to expose a general vendor string when using KVM. Hence the 'all other things are equal' clause. True, CPU vendor is special. And the tricky part is the all other things are equal clause. e.g.: we try to keep all guest-visible features the same when using -M even if the host CPU or the host kernel changes. So the host kernel and the host CPU aren't included in the all other things are equal clause, but the host CPU vendor is. In other words: we don't support cross-CPU-vendor migration out of the box (and if somebody wants to try to make it work, it will require an explicit CPu vendor to be always set on the command-line). In another case, we are considering making other properties of a X86CPU subclass have different defaults depending on the capabilities of the host kernel (the host CPU class will have different feature property defaults depending on the capabilities reported by GET_SUPPORTED_CPUID). Would that be OK, too? Given 'all other things are equal', yes, it would be. -cpu host is known and expected to _really_ stretch the all other things are equal part of rule (3). Other CPU models are kept compatible even if the host CPU or host kernel changes (as long as the host CPU has the same vendor). host keeps rule (3) if and only if the host kernel CPUID capabilities and the host CPU are exactly the same. I would go further and simply declare -cpu host as not following rule (3) at all, instead of trying to define the specific conditions where it would follow it. FWIW, I agree with the suggestion elsewhere in the thread that instead of changing default values, an auto detect value is a more user friendly way of having this behavior. Are you talking about the suggestion of having vendor default to host, and having instance_init translate vendor=host to the host CPU vendor? My main argument for it was the possibility of not being allowed to change the defaults based on host CPU. But if we are allowed to change the default, do we still want to use the vendor=host solution? (My opinion is now divided, but I am inclined towards it). -- Eduardo
