Re: [PATCH] KVM: X86: Extend MAX_IRQ_ROUTES to 4096

[Cornelia Huck]

On Thu, 19 Apr 2018 13:42:55 +0000
Wanpeng Li <wanpeng.li@xxxxxxxxxxx> wrote:

> On Thu, 19 Apr 2018 05:30:40 -0700
> 
> Wanpeng Li <kernellwp@xxxxxxxxx> wrote:
> 
> > From: Wanpeng Li <wanpengli@xxxxxxxxxxx>
> >
> > Our virtual machines make use of device assignment by configuring
> > 12 NVMe disks for high I/O performance. Each NVMe device has 129
> > MSI-X Table entries:
> > Capabilities: [50] MSI-X: Enable+ Count=129 Masked-Vector table: BAR=0 offset=00002000
> > The windows virtual machines fail to boot since they will map the number of
> > MSI-table entries that the NVMe hardware reported to the bus to msi routing
> > table, this will exceed the 1024. This patch extends MAX_IRQ_ROUTES to 4096,
> > In the future this might be extended if needed.
> >
> > Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> > Cc: Radim KrÄmÃÅ <rkrcmar@xxxxxxxxxx>
> > Cc: Tonny Lu <tonnylu@xxxxxxxxxxx>
> > Signed-off-by: Wanpeng Li <wanpengli@xxxxxxxxxxx>
> > Signed-off-by: Tonny Lu <tonnylu@xxxxxxxxxxx>
> > ---
> >  include/linux/kvm_host.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index 6930c63..815ae66 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -1050,7 +1050,7 @@ static inline int mmu_notifier_retry(struct kvm *kvm, unsigned long mmu_seq)
> >  #elif defined(CONFIG_ARM64)
> >  #define KVM_MAX_IRQ_ROUTES 4096
> >  #else
> > -#define KVM_MAX_IRQ_ROUTES 1024
> > +#define KVM_MAX_IRQ_ROUTES 4096
> >  #endif
> >
> >  bool kvm_arch_can_set_irq_routing(struct kvm *kvm);  
> 
> So, this basically means we have 4096 everywhere, no?
> 
> I suspect different architectures maybe extend to different limits again according to their requirements.

Yes, but for now, we have the same everywhere (as you also bumped the
limit on power and 32-bit arm, implicitly). If that's ok, we might as
well get rid of the ifdeffery.

Also, my additional remark in f3f710bc64e12 still holds:

"We need to find a more general solution, though, as we can't just grow
the routing table indefinitly."