From patchwork Wed Nov 22 19:20:23 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: George Dunlap X-Patchwork-Id: 10070833 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id F19F26038F for ; Wed, 22 Nov 2017 19:30:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E64F329DA5 for ; Wed, 22 Nov 2017 19:30:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DB27E29DC9; Wed, 22 Nov 2017 19:30:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 7F86329DA5 for ; Wed, 22 Nov 2017 19:30:55 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHahH-0000HZ-20; Wed, 22 Nov 2017 19:28:35 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHahG-0000G6-0J for xen-devel@lists.xenproject.org; Wed, 22 Nov 2017 19:28:34 +0000 Received: from [193.109.254.147] by server-1.bemta-6.messagelabs.com id F7/E6-12020-1EFC51A5; Wed, 22 Nov 2017 19:28:33 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRWlGSWpSXmKPExsXitHRDpO6D86J RBnd2all83zKZyYHR4/CHKywBjFGsmXlJ+RUJrBkbjv5jLngqVtG5v4upgXGfUBcjJ4eEgL/E 6y1fGUFsNgE9iXnHv7J0MXJwiAioSNzea9DFyMXBLLCOSWJZ40dWkBphAROJm7vaWEBsFgFVi Vt3roP18grYSezdOYcJYqa8xOLvO9lAbE6g+KPJ88FsIQFbiVNb5zJD2KoSix8cZYfoFZQ4Of MJ2ExmAQmJgy9eME9g5J2FJDULSWoBI9MqRvXi1KKy1CJdE72kosz0jJLcxMwcXUMDM73c1OL ixPTUnMSkYr3k/NxNjMDQYQCCHYzdl/0PMUpyMCmJ8gYvF4kS4kvKT6nMSCzOiC8qzUktPsQo w8GhJMFbeE40SkiwKDU9tSItMwcYxDBpCQ4eJRHeDpA0b3FBYm5xZjpE6hSjMcezma8bmDmmX W1tYhZiycvPS5US57UBKRUAKc0ozYMbBIuuS4yyUsK8jECnCfEUpBblZpagyr9iFOdgVBLmLQ GZwpOZVwK37xXQKUxAp/w8LgxySkkiQkqqgVG2eI8xZ5KY4OPDf2orZ/3+Ps1hWfDVebntn96 /z+Xb3Vg4aWIBo7mIjVfK/9PJksobjgjNT1tTvCtzWtyc/+vnvLw4NX763Gg1xdjGNyU/i5sy mOxZ7yar+DQ7/hEKbLNZcV0tV+HzWYv3F7u/VmfxnJvPsuaC379DOkGV8xYsfTfpZc6VBwlKL MUZiYZazEXFiQB4SOJHqQIAAA== X-Env-Sender: prvs=49202577f=George.Dunlap@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1511378909!64859279!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15645 invoked from network); 22 Nov 2017 19:28:32 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Nov 2017 19:28:32 -0000 X-IronPort-AV: E=Sophos;i="5.44,436,1505779200"; d="scan'208";a="452652886" From: George Dunlap To: Date: Wed, 22 Nov 2017 19:20:23 +0000 Message-ID: <20171122192024.21187-16-george.dunlap@citrix.com> X-Mailer: git-send-email 2.15.0 In-Reply-To: <20171122192024.21187-1-george.dunlap@citrix.com> References: <20171122192024.21187-1-george.dunlap@citrix.com> MIME-Version: 1.0 Cc: Stefano Stabellini , Wei Liu , Konrad Wilk , Andrew Cooper , Tim Deegan , George Dunlap , Jan Beulich , Ian Jackson Subject: [Xen-devel] [PATCH v3 16/17] SUPPORT.md: Add limits RFC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP Signed-off-by: George Dunlap --- Changes since v2: - Update memory limits for PV guests CC: Ian Jackson CC: Wei Liu CC: Andrew Cooper CC: Jan Beulich CC: Stefano Stabellini CC: Konrad Wilk CC: Tim Deegan --- SUPPORT.md | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 67 insertions(+), 1 deletion(-) diff --git a/SUPPORT.md b/SUPPORT.md index aa58fb0de3..72be1414a1 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -62,6 +62,58 @@ for the definitions of the support status levels etc. Extension to the GICv3 interrupt controller to support MSI. +## Limits/Host + +### CPUs + + Limit, x86: 4095 + Limit, ARM32: 8 + Limit, ARM64: 128 + +Note that for x86, very large number of cpus may not work/boot, +but we will still provide security support + +### x86/RAM + + Limit, x86: 123TiB + Limit, ARM32: 16GiB + Limit, ARM64: 5TiB + +## Limits/Guest + +### Virtual CPUs + + Limit, x86 PV: 8192 + Limit-security, x86 PV: 32 + Limit, x86 HVM: 128 + Limit-security, x86 HVM: 32 + Limit, ARM32: 8 + Limit, ARM64: 128 + +### Virtual RAM + + Limit-security, x86 PV 64-bit: 2047GiB + Limit-security, x86 PV 32-bit: 168GiB (see below) + Limit-security, x86 HVM: 1.5TiB + Limit, ARM32: 16GiB + Limit, ARM64: 1TiB + +Note that there are no theoretical limits to 64-bit PV or HVM guest sizes +other than those determined by the processor architecture. + +All 32-bit PV guest memory must be under 168GiB; +this means the total memory for all 32-bit PV guests cannot exced 168GiB. +On larger hosts, this limit is 128GiB. + +### Event Channel 2-level ABI + + Limit, 32-bit: 1024 + Limit, 64-bit: 4096 + +### Event Channel FIFO ABI + + Limit: 131072 + ## Guest Type ### x86/PV @@ -634,7 +686,7 @@ that covers the DMA of the device to be passed through. Status: Supported, with caveats -No support for QEMU backends in a 16K or 64K domain. +No support for QEMU backends bin a 16K or 64K domain. ### ARM: Guest Devicetree support @@ -736,6 +788,20 @@ If support differs based on implementation (for instance, x86 / ARM, Linux / QEMU / FreeBSD), one line for each set of implementations will be listed. +### Limit-security + +For size limits. +This figure shows the largest configuration which will receive +security support. +It is generally determined by the maximum amount that is regularly tested. +This limit will only be listed explicitly +if it is different than the theoretical limit. + +### Limit + +This figure shows a theoretical size limit. +This does not mean that such a large configuration will actually work. + ## Definition of Status labels Each Status value corresponds to levels of security support,