Re: [PATCH v2 11/13] KVM: x86: add KVM_CAP_X2APIC_API

From: Yang Zhang
Date: Mon Jul 11 2016 - 06:34:25 EST

On 2016/7/11 17:17, Paolo Bonzini wrote:

On 11/07/2016 10:56, Yang Zhang wrote:
On 2016/7/11 15:44, Paolo Bonzini wrote:

On 11/07/2016 08:06, Yang Zhang wrote:
Changes to MSI addresses follow the format used by interrupt remapping
The upper address word, that used to be 0, contains upper 24 bits of
address in its upper 24 bits. Lower 8 bits are reserved as 0.
Using the upper address word is not backward-compatible either as we
check that userspace zeroed the word. Reserved bits are still not

Does this means we cannot migrate the VM from KVM_CAP_X2APIC_API enabled
host to the disable host even VM doesn't have more than 255 VCPUs?

Yes, but that's why KVM_CAP_X2APIC_API is enabled manually. The idea is
that QEMU will not use KVM_CAP_X2APIC_API except on the newest machine

Thanks for confirmation. And when the KVM_CAP_X2APIC_API will be enabled
in Qemu?

It could be 2.7 or 2.8.

If interrupt remapping is on, KVM_CAP_X2APIC_API is needed even with 8
VCPUs, I think. Otherwise KVM will believe that 0xff is "broadcast"
rather than "cluster 0, CPUs 0-7".

If interrupt remapping is using, what 0xff means is relying on which
mode the destination CPU is in. I think there is no KVM_CAP_X2APIC_API
needed since interrupt remapping table gives all the information.

If you have EIM 0xff never means broadcast, but KVM sees a 0xff in the
interrupt route or KVM_SIGNAL_MSI argument and translates it into a

I see your point. I thought there would be a new irq router(like KVM_IRQ_ROUTING_IR) to handle all interrupts after turn on IR and KVM_CAP_X2APIC_API would be dropped. So we will continue to use KVM_IRQ_ROUTING_IRQCHIP and KVM_IRQ_ROUTING_MSI for interrupt from IR, right?

best regards