On Thu, Feb 06, 2014 at 05:57:38PM +0100, Andreas Färber wrote: [...] > >> If there's no relation between a CPU model named, e.g., "Haswell" and > >> the one on an Intel Haswell chip any more, then we should give them > >> artificial names like "qemu64"; I strongly believe that Haswell > >> definition in code should match that of the specs/hardware and if TCG > >> can't emulate something that's one thing (subtractive: no AVX) and if > >> KVM wants to speed up things that's another (additive: kvmvapic, > >> in-kernel IRQ/PIT). What I am arguing against is watering the meaning of > >> our definitions from "this is this model" to "this is handy". In > >> particular, if we use the post_initialize hook like I suggested then > >> -global is still able to override it and Eduardo's properties should > >> correctly report them to libvirt. > > > > "Haswell" is named this way not only because it looks like Haswell, but > > also because it has useful features you are going to find only on > > Haswell, and you (probably) are not going to be able to run it on hosts > > older than Haswell. That's the main real-world application of CPU > > models: making sure the VMs can run on a specific subset of hosts. So, > > if you choose "Haswell", you are telling the management stack "I know > > this is going to run only on Haswell and newer CPUs". > > > > That's why x2apic is being proposed as an exception: it can be enabled > > on any host, because it doesn't depend on host-side support. That's why > > I propose we enable it on CPU models that don't have x2apic in the real > > world. > > > > (BTW, what is the relation between this subject and static properties? I > > was expecting this to be discussed in the other existing thread about > > x2apic) > > Sorry if I replied to two different series at once, that was for > "Enabling x2apic by default in KvM (was Re: [Qemu-devel] [PATCH] > target-i386: enable x2apic by default on more recent CPU models)". > > Which is connected to CPU models/subclasses in what those types are > supposed to be good for if we define them. > > Let's take an obvious example. Jan wants to emulate a legacy isapc > machine with -cpu 486. Then it feels counterproductive to enable the > latest and greatest features such a machine never had. If the user wants > to have the latest and greatest features, she can choose a newer -cpu > model which already has the flag today. OK, trying to be pragmatic: First, my main assumption: we don't want to make CPU models look different in KVM and TCG mode, to keep the CPU model information APIs simple and sane. Based on that: * I understand you don't want to force Jan to use "-cpu 486,-x2apic" * I don't want to force libvirt to use "-cpu Opteron_G1,+x2apic" I don't care about not having x2apic on 486 and other older CPU models that are fully supported by TCG, and I believe people using TCG won't care about having x2apic on Opteron_G1 and newer in the near future. One day TCG may be able to run Opteron_G1 too. But I also believe that the QEMU interfaces and the libvirt code that handles CPU features will eventually get mature enough so libvirt will be less affected by QEMU's decision about feature flags in CPU models. When that happen, we will be able to disable x2apic on Opteron_G1 and let libvirt enable it explicitly. Considering that, isn't it a reasonable compromise to add x2apic to the CPU models that today are useful only for KVM? -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list