Received: by 10.192.165.148 with SMTP id m20csp324812imm; Fri, 20 Apr 2018 07:23:28 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+EJI6wNc/DYGOUaixceh8MuwlCsLnocVjJldNUzuQuCgwGlkwR0fKFjFrI6ilZ9bJTyUL6 X-Received: by 10.101.100.193 with SMTP id t1mr3845754pgv.406.1524234208017; Fri, 20 Apr 2018 07:23:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524234207; cv=none; d=google.com; s=arc-20160816; b=BZeRL+5JA6pwYFBFrpln7cvDJ6AqxTZO0+RzRZg+Fu9lhqKByiTbdyKkeKdhdrkFr0 bGME2RcJPtfkU27vu7i0CqOfbP7IQPRPnXic7EktlHhVcXOhw1joh4yn+UZUIMzh5a9E NkrnnN5lGII70ycBfhtFoxcEFcORfvlTbiOUnE55BZL0xsPfpveXfB6h6WazDmc3XZah aX9HnLXvOmWImJyWuh7I8Y3DEsToZ0U2C62ZBw2aF663SmYBL1mwDKWV5rGH1dLIn2R8 S10oycdChpCZHNuA6aeuYOJ5D6Cga50SZpdbsqtZLIdVzvXoLtp8WrCJJJk3A0yEzXyp Rv6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=ZvcSyVVRIXU9wkfsCPVJHcjvk1h36XxNYkeVC4AEyiw=; b=QoSUSvW/aavu9GH+q7nAcnSKiSJdb4aEIWwDkgd+GF2awwgmAnsDblhGcOwBmhEvaJ L7G4RPrdo9PGtJ39W8F95cL8J8pNl8a9QTGLMHvLB9nEXYjvtsAgJqhJapsxl7hRpFC1 DKy7iyAvFr9/sqwlduIsDxiMGHMhAOqVt5LOAwFpE4wDi/pIZsrp5kATw4JIaEf/0lEx XLXMeNE7du3dPpmUnoMZ/rOR4xj4L18k4PtzvT2Tt3sv5f+/84rsPFk7EKPYlrXhG0GD E9OHzUqzL8HRbOJV4NsMtsMxqgd9hm0FzoVBCgVUWlbEEXRe9ObxftApd6sGo+X7hZAs 1NUA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i198si2999341pgc.340.2018.04.20.07.23.13; Fri, 20 Apr 2018 07:23:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755230AbeDTOWB convert rfc822-to-8bit (ORCPT + 99 others); Fri, 20 Apr 2018 10:22:01 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:46710 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755192AbeDTOV7 (ORCPT ); Fri, 20 Apr 2018 10:21:59 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 60565F1207; Fri, 20 Apr 2018 14:21:59 +0000 (UTC) Received: from gondolin (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id ABB89215CDA7; Fri, 20 Apr 2018 14:21:57 +0000 (UTC) Date: Fri, 20 Apr 2018 16:21:55 +0200 From: Cornelia Huck To: Wanpeng Li Cc: LKML , kvm , Paolo Bonzini , Radim =?UTF-8?B?S3LEjW3DocWZ?= , Tonny Lu , Christian Borntraeger , Janosch Frank Subject: Re: [PATCH v2] KVM: Extend MAX_IRQ_ROUTES to 4096 for all archs Message-ID: <20180420162155.675d516d.cohuck@redhat.com> In-Reply-To: References: <1524185248-51744-1-git-send-email-wanpengli@tencent.com> <20180420091537.1c6cb06b.cohuck@redhat.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 20 Apr 2018 14:21:59 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 20 Apr 2018 14:21:59 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'cohuck@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 Apr 2018 21:51:13 +0800 Wanpeng Li wrote: > 2018-04-20 15:15 GMT+08:00 Cornelia Huck : > > On Thu, 19 Apr 2018 17:47:28 -0700 > > Wanpeng Li wrote: > > > >> From: Wanpeng Li > >> > >> 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 > >> for all archs, in the future this might be extended again if needed. > >> > >> Cc: Paolo Bonzini > >> Cc: Radim Krčmář > >> Cc: Tonny Lu > >> Cc: Cornelia Huck > >> Signed-off-by: Wanpeng Li > >> Signed-off-by: Tonny Lu > >> --- > >> v1 -> v2: > >> * extend MAX_IRQ_ROUTES to 4096 for all archs > >> > >> include/linux/kvm_host.h | 6 ------ > >> 1 file changed, 6 deletions(-) > >> > >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > >> index 6930c63..0a5c299 100644 > >> --- a/include/linux/kvm_host.h > >> +++ b/include/linux/kvm_host.h > >> @@ -1045,13 +1045,7 @@ static inline int mmu_notifier_retry(struct kvm *kvm, unsigned long mmu_seq) > >> > >> #ifdef CONFIG_HAVE_KVM_IRQ_ROUTING > >> > >> -#ifdef CONFIG_S390 > >> #define KVM_MAX_IRQ_ROUTES 4096 //FIXME: we can have more than that... > > > > What about /* might need extension/rework in the future */ instead of > > the FIXME? > > Yeah, I guess the maintainers can help to fix it when applying. :) > > > > > As far as I understand, 4096 should cover most architectures and the > > sane end of s390 configurations, but will not be enough at the scarier > > end of s390. (I'm not sure how much it matters in practice.) > > > > Do we want to make this a tuneable in the future? Do some kind of > > dynamic allocation? Not sure whether it is worth the trouble. > > I think keep as it is currently. My main question here is how long this is enough... the number of virtqueues per device is up to 1K from the initial 64, which makes it possible to hit the 4K limit with fewer virtio devices than before (on s390, each virtqueue uses a routing table entry). OTOH, we don't want giant tables everywhere just to accommodate s390. If the s390 maintainers tell me that nobody is doing the really insane stuff, I'm happy as well :)