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

[Yang Zhang]

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