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
unit.
The upper address word, that used to be 0, contains upper 24 bits of
the LAPIC
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
didn't
check that userspace zeroed the word. Reserved bits are still not
explicitly
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
type.
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
broadcast.
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
yang
--
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
