Rik van Riel wrote: > On 03/09/2012 01:27 PM, Liu, Jinsong wrote: > >> As for 'tsc deadline' feature exposing, my patch (as attached) just >> obey qemu general cpuid exposing method, and also satisfied your >> target I think. > > One question. > > Why is TSC_DEADLINE not exposed in the cpuid allowed feature > bits in do_cpuid_ent() in arch/x86/kvm/x86.c ? > > /* cpuid 1.ecx */ > const u32 kvm_supported_word4_x86_features = > F(XMM3) | F(PCLMULQDQ) | 0 /* DTES64, MONITOR */ | > 0 /* DS-CPL, VMX, SMX, EST */ | > 0 /* TM2 */ | F(SSSE3) | 0 /* CNXT-ID */ | 0 /* > Reserved */ | > F(FMA) | F(CX16) | 0 /* xTPR Update, PDCM */ | > 0 /* Reserved, DCA */ | F(XMM4_1) | > F(XMM4_2) | F(X2APIC) | F(MOVBE) | F(POPCNT) | > 0 /* Reserved*/ | F(AES) | F(XSAVE) | 0 /* OSXSAVE > */ | F(AVX) | > F(F16C) | F(RDRAND); > > Would it make sense to expose F(TSC_DEADLINE) above? > > Or is there something truly special about tsc deadline > that means it should be different from everything else?
Because the feature depends on KVM_CREATE_IRQCHIP, which we cannot guarantee will be called, we expose it via a KVM_CAP_TSC_DEADLINE_TIMER and not KVM_GET_SUPPORTED_CPUID. Refer changeset 4d25a066b69fb749a39d0d4c610689dd765a0b0e. BTW, your question remind me qemu-kvm side patch, and I update it a little (would be sent out later). Thanks, Jinsong