On 13/07/2016 17:14, Radim Krčmář wrote:
> 2016-07-13 10:38+0200, Paolo Bonzini:
>> On 12/07/2016 22:09, Radim Krčmář wrote:
>>> @@ -619,14 +619,17 @@ static bool kvm_apic_match_logical_addr(struct kvm_lapic *apic, u32 mda)
>>> /* KVM APIC implementation has two quirks
>>> * - dest always begins at 0 while xAPIC MDA has offset 24,
>>> * - IOxAPIC messages have to be delivered (directly) to x2APIC.
>>> + *
>>> + * The broadcast quirk can be disabled with KVM_CAP_X2APIC_API.
>>
>> --verbose version:
>>
>> /* KVM APIC implementation has two quirks
>> - * - dest always begins at 0 while xAPIC MDA has offset 24,
>> - * - IOxAPIC messages have to be delivered (directly) to x2APIC.
>> + * - dest always begins at 0 while xAPIC MDA has offset 24. This is
>> + * just a quirk in the API and is not problematic.
>> *
>> - * The broadcast quirk can be disabled with KVM_CAP_X2APIC_API.
>> + * - in-kernel IOAPIC messages have to be delivered directly to
>> + * x2APIC, because the kernel does not support interrupt remapping.
>> + * In order to support broadcast without interrupt remapping, x2APIC
>> + * rewrites the destination of non-IPI messages (and also of IPIs sent
>> + * from xAPIC-mode LAPICs) from APIC_BROADCAST to X2APIC_BROADCAST.
>
> KVM doesn't do the operation in parentheses since 394457a928e0 ("KVM:
> x86: some apic broadcast modes does not work").
>
> Following patches added only !ipi case (I already regret posting them).
>
>> + *
>> + * The broadcast quirk can be disabled with KVM_CAP_X2APIC_API. This is
>> + * important when userspace wants to use x2APIC-format MSIs, because
>> + * APIC_BROADCAST (0xff) is a legal route for "cluster 0, CPUs 0-7".
>> */
>>
>> Sounds good?
>
> Except that one bit. (Code alone really can't explain the what happens
> here.)
>
Ok, will fix both bits tomorrow and repush to kvm/queue. Then test,
push to kvm/next, and pass the tree to you.
Thanks!
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
