On Thu, Aug 24, 2017 at 16:29:37 +0800, Jay Zhou wrote: > Hi all, > > "f16c", "rdrand" and "vme" are all standard features, the IvyBridge CPU model > has these three features in the file of src/cpu/cpu_map.xml, but the higher > model of Haswell-noTSX, Haswell, Broadwell-noTSX and Broadwell do not, which > makes it incompatible. > BTW, I noticed that "f16c", "rdrand" and "vme" are a part of features of > Haswell-noTSX, Haswell, Broadwell-noTSX and Broadwell in QEMU. > > The commit 732d3d147adecb867f62c67ab3743c0aefd87e50(which introduces the > Haswell-noTSX CPU model in libvirt) said that: > > "Inheritance among CPU model is cool but it makes reviewing CPU model > definitions and comparing them to CPU models from QEMU rather hard and > unpleasant." > > I do not get the point "it makes reviewing CPU model definitions and comparing > them to CPU models from QEMU rather hard and unpleasant" clearly. Could anyone > explain it more explicitly? CPU models in QEMU always contain a full list of CPU features. Before the commit you mentioned libvirt defined CPU models hierarchically as MODEL_B = MODEL_A + feature_a + feature_b. Getting a complete list of features contained in a MODEL_B required a lot of work since you had to go through MODEL_A, its parent, its parent's parent, and so on. To make manual comparing of libvirt's models with QEMU easier, we decided to expand the feature set of each CPU model and drop the hierarchical definitions. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
