On Fri, Apr 26, 2013 at 07:41:10PM +0200, Igor Mammedov wrote: > On Fri, 26 Apr 2013 14:30:40 -0300 > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > On Fri, Apr 26, 2013 at 05:39:15PM +0200, Igor Mammedov wrote: > > > On Fri, 26 Apr 2013 17:33:18 +0200 > > > Andreas Färber <afaer...@suse.de> wrote: > > > > > > > Am 26.04.2013 17:31, schrieb Eduardo Habkost: > > > > > On Fri, Apr 26, 2013 at 05:10:29PM +0200, Igor Mammedov wrote: > > > > >> On Thu, 25 Apr 2013 15:43:06 -0300 > > > > >> Eduardo Habkost <ehabk...@redhat.com> wrote: > > > > >> > > > > >>> The current code handling the CPUID 0xA leaf simply forwards all > > > > >>> data > > > > >>> from GET_SUPPORTED_CPUID directly to the guest, breaking migration > > > > >>> between hosts with different number of PMU counters. > > > > >>> > > > > >>> This patch disables this behavior, except on older machine-types > > > > >>> (for > > > > >>> compatibility) and on the "host" CPU model. > > > > >> Please, make it static property and use compat properties. > > > > >> Result will be simpler and much less will have to be > > > > >> redone/discarded after > > > > >> converting to the rest to properties and sub-classes. > > > > > > > > > > I was going to say that static properties were too much work to be > > > > > done > > > > > in time for 1.5, but you are right: in this specific case adding a > > > > > static property for the cpuid_pmu_passthrough field looks very easy. I > > > > > will give it a try. > > > > > > > > I am hoping to get as initial set (though not all) of the static > > > > properties still into 1.5. Using them to fix CPUID bugs can then be done > > > > during Hard Freeze. :) > > > patch "[PATCH 02/10] target-i386: cpu: convert existing dynamic properties > > > into static properties" should be enough for using model,level compat > > > properties. > > > > ...except that we don't have X86CPU model subclasses yet, so we can't > > set model-specific compat properties using compat_props. > X86CPU could serve here
How? If we need to set model=8 only on the "486" CPU model, how would we do that in the compat_props table without subclasses? > > > > > Maybe we can make compat_props work for pmu-passthrough, but it may be > > not completely straightforward because I would like to keep it enabled > > by default on -cpu host. > Maybe for 'host' hack realize() to override default, will do and later we > can move it to host_subclass. Yes, it's doable. And I don't think we even need to hack methods, we just need a x86_def_t field that indicates that this is a model that overrides the default (and that field would be true only for "host"). But I still don't see how it would be possible to use compat_props for the 486 model=8 fix or for the n270 movbe fix. -- Eduardo
