Am 03.02.2014 20:01, schrieb Eduardo Habkost: > On Tue, Jan 21, 2014 at 05:13:50PM +0100, Paolo Bonzini wrote: >> Il 21/01/2014 16:51, Andreas Färber ha scritto: >>>>> We already do that for other bits (e.g. XSAVE/OSXSAVE), >>> Please point me to the commit, a search for xsave did not come up with a >>> commit changing such a thing - either it did not go through my queue or >>> it slipped me through: Bugs are no excuse to produce more bugs. >> >> I meant that "-cpu SandyBridge" with TCG produces a CPU that doesn't >> have XSAVE. >> >>>>> and in fact it >>>>> is the same that we do for KVM: the KVM_GET_SUPPORTED_CPUID result is >>>>> used to trim the generic feature bits. >>> Our model definitions are the place to put stuff that real CPUs have. >>> Either the CPU has it or it doesn't. If it does, then this patch is >>> fully correct and it's TCG's job to mask things out. If we're adding >>> artificial flags to the generic model definitions just to make KVM >>> faster, then it is wrong - we have a choice of post_initialize and >>> realize hooks for that. >> >> It would make TCG faster as well, and there would be no reason >> really to avoid the "artificial" x2apic on TCG, if TCG implemented >> x2apic at all. > > So, the discussion seem to have stalled. > > Andreas, are you still against the patch, after the arguments from Paolo > and me? Yes, I am. I had proposed to discuss solutions at FOSDEM but Paolo was not there, so no solution yet. My main concern still is that if a CPU does not have a certain feature we should not list it as one of its features but add it to its features where sensible. Just because TCG filters it out today is not keeping anyone from implementing it tomorrow, in which case the emulated CPUs would suddenly gain the feature. So my question still is, what rule can we apply for enabling x2apic? (something like greater or equal this family, etc. - then we can put it in your post_initialize hook so that users can still override it)