LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Wanpeng Li <wanpeng.li@hotmail.com>
Cc: "Wanpeng Li" <kernellwp@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Tonny Lu" <tonnylu@tencent.com>
Subject: Re: [PATCH] KVM: X86: Extend MAX_IRQ_ROUTES to 4096
Date: Thu, 19 Apr 2018 16:09:29 +0200	[thread overview]
Message-ID: <20180419160929.2c2f5e1b.cohuck@redhat.com> (raw)
In-Reply-To: <KL1PR02MB1301D3C3A62E6CED2530496180B50@KL1PR02MB1301.apcprd02.prod.outlook.com>

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

> On Thu, 19 Apr 2018 05:30:40 -0700
> 
> Wanpeng Li <kernellwp@gmail.com> wrote:
> 
> > From: Wanpeng Li <wanpengli@tencent.com>
> >
> > 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@redhat.com>
> > Cc: Radim Krčmář <rkrcmar@redhat.com>
> > Cc: Tonny Lu <tonnylu@tencent.com>
> > Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
> > Signed-off-by: Tonny Lu <tonnylu@tencent.com>
> > ---
> >  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."

  parent reply	other threads:[~2018-04-19 14:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19 12:30 Wanpeng Li
2018-04-19 13:06 ` Cornelia Huck
     [not found]   ` <KL1PR02MB1301D3C3A62E6CED2530496180B50@KL1PR02MB1301.apcprd02.prod.outlook.com>
2018-04-19 14:09     ` Cornelia Huck [this message]
2018-04-20  0:55       ` Wanpeng Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180419160929.2c2f5e1b.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=kernellwp@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=tonnylu@tencent.com \
    --cc=wanpeng.li@hotmail.com \
    --subject='Re: [PATCH] KVM: X86: Extend MAX_IRQ_ROUTES to 4096' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).