On 03/10/2018 14:14, Jim Mattson wrote: > On Wed, Oct 3, 2018 at 1:29 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >> On 01/10/2018 23:25, Sean Christopherson wrote: >>> kvm-intel.flexpriority is a >>> haphazard param that is inconsistently honored by KVM, e.g. it still >>> controls VIRTUALIZE_APIC_ACCESSES but not TPR_SHADOW, CR8-exiting or >>> VIRTUALIZE_X2APIC_MODE >> >> This is on purpose: the original purpose of VIRTUALIZE_APIC_ACCESSES was >> to speed up Windows XP and 2003, which didn't use CR8. Processors >> without it could already execute newer Windows versions without the >> overhead of emulating TPR accesses (notice how VIRTUALIZE_APIC_ACCESSES >> is a secondary execution control, while TPR_SHADOW is a primary control). > > If the setting is only for specific guests, why is it a kernel > parameter rather than a per-VM capability? Do you mean the flexpriority module parameter or VIRTUALIZE_APIC_ACCESSES? VIRTUALIZE_APIC_ACCESSES does nothing on newer Windows guests, because they use CR8 to write to the TPR. However, it's also not a problem if you enable it. The flexpriority module parameter instead is a kernel parameter because it's really only useful for debugging problems that only happen on old machines (and to a lesser extent, problems that only happen on pre-AVIC AMD machines). Making it a per-VM capability would not be particularly interesting, and it adds weight to the userspace ABI compatibility (userspace ABI for example is the reason why we cannot drop userspace irqchip support). But since these machines still exist and people are using KVM on them, we have to keep the debugging aid around. Paolo
