[PATCH v3 01/17] Introduce skeleton SUPPORT.md

[PATCH v3 01/17] Introduce skeleton SUPPORT.md

[George Dunlap]

Add a machine-readable file to describe what features are in what
state of being 'supported', as well as information about how long this
release will be supported, and so on.

The document should be formatted using "semantic newlines" [1], to make
changes easier.

Begin with the basic framework.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

[1] http://rhodesmill.org/brandon/2012/one-sentence-per-line/
---
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Dario Faggioli <dario.faggioli@citrix.com>
CC: Tamas K Lengyel <tamas.lengyel@zentific.com>
CC: Roger Pau Monne <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Anthony Perard <anthony.perard@citrix.com>
CC: Paul Durrant <paul.durrant@citrix.com>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Julien Grall <julien.grall@arm.com>
---
 SUPPORT.md | 194 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 SUPPORT.md

diff --git a/SUPPORT.md b/SUPPORT.md
new file mode 100644
index 0000000000..e3d5d1de8d
--- /dev/null
+++ b/SUPPORT.md
@@ -0,0 +1,194 @@
+# Support statement for this release
+
+This document describes the support status
+and in particular the security support status of the Xen branch
+within which you find it.
+
+See the bottom of the file
+for the definitions of the support status levels etc.
+
+# Release Support
+
+    Xen-Version: 4.10-unstable
+    Initial-Release: n/a
+    Supported-Until: TBD
+    Security-Support-Until: Unreleased - not yet security-supported
+
+# Feature Support
+
+# Format and definitions
+
+This file contains prose, and machine-readable fragments.
+The data in a machine-readable fragment relate to
+the section and subsection in which it is found.
+
+The file is in markdown format.
+The machine-readable fragments are markdown literals
+containing RFC-822-like (deb822-like) data.
+
+## Keys found in the Feature Support subsections
+
+### Status
+
+This gives the overall status of the feature,
+including security support status, functional completeness, etc.
+Refer to the detailed definitions below.
+
+If support differs based on implementation
+(for instance, x86 / ARM, Linux / QEMU / FreeBSD),
+one line for each set of implementations will be listed.
+
+## Definition of Status labels
+
+Each Status value corresponds to levels of security support,
+testing, stability, etc., as follows:
+
+### Experimental
+
+    Functional completeness: No
+    Functional stability: Here be dragons
+    Interface stability: Not stable
+    Security supported: No
+
+### Tech Preview
+
+    Functional completeness: Yes
+    Functional stability: Quirky
+    Interface stability: Provisionally stable
+    Security supported: No
+
+#### Supported
+
+    Functional completeness: Yes
+    Functional stability: Normal
+    Interface stability: Yes
+    Security supported: Yes
+
+#### Deprecated
+
+    Functional completeness: Yes
+    Functional stability: Quirky
+    Interface stability: No (as in, may disappear the next release)
+    Security supported: Yes
+
+All of these may appear in modified form.
+There are several interfaces, for instance,
+which are officially declared as not stable;
+in such a case this feature may be described as "Stable / Interface not stable".
+
+## Definition of the status label interpretation tags
+
+### Functionally complete
+
+Does it behave like a fully functional feature?
+Does it work on all expected platforms,
+or does it only work for a very specific sub-case?
+Does it have a sensible UI,
+or do you have to have a deep understanding of the internals
+to get it to work properly?
+
+### Functional stability
+
+What is the risk of it exhibiting bugs?
+
+General answers to the above:
+
+ * **Here be dragons**
+
+   Pretty likely to still crash / fail to work.
+   Not recommended unless you like life on the bleeding edge.
+
+ * **Quirky**
+
+   Mostly works but may have odd behavior here and there.
+   Recommended for playing around or for non-production use cases.
+
+ * **Normal**
+
+   Ready for production use
+
+### Interface stability
+
+If I build a system based on the current interfaces,
+will they still work when I upgrade to the next version?
+
+ * **Not stable**
+
+   Interface is still in the early stages and
+   still fairly likely to be broken in future updates.
+
+ * **Provisionally stable**
+
+   We're not yet promising backwards compatibility,
+   but we think this is probably the final form of the interface.
+   It may still require some tweaks.
+
+ * **Stable**
+
+   We will try very hard to avoid breaking backwards  compatibility,
+   and to fix any regressions that are reported.
+
+### Security supported
+
+Will XSAs be issued if security-related bugs are discovered
+in the functionality?
+
+If "no",
+anyone who finds a security-related bug in the feature
+will be advised to
+post it publicly to the Xen Project mailing lists
+(or contact another security response team,
+if a relevant one exists).
+
+Bugs found after the end of **Security-Support-Until**
+in the Release Support section will receive an XSA
+if they also affect newer, security-supported, versions of Xen.
+However, the Xen Project will not provide official fixes
+for non-security-supported versions.
+
+Three common 'diversions' from the 'Supported' category
+are given the following labels:
+
+  * **Supported, Not security supported**
+
+    Functionally complete, normal stability,
+    interface stable, but no security support
+
+  * **Supported, Security support external**
+
+    This feature is security supported
+    by a different organization (not the XenProject).
+    See **External security support** below.
+
+  * **Supported, with caveats**
+
+    This feature is security supported only under certain conditions,
+    or support is given only for certain aspects of the feature,
+    or the feature should be used with care
+    because it is easy to use insecurely without knowing it.
+    Additional details will be given in the description.
+
+### Interaction with other features
+
+Not all features interact well with all other features.
+Some features are only for HVM guests; some don't work with migration, &c.
+
+### External security support
+
+The XenProject security team
+provides security support for XenProject projects.
+
+We also provide security support for Xen-related code in Linux,
+which is an external project but doesn't have its own security process.
+
+External projects that provide their own security support for Xen-related features are listed below.
+
+  * QEMU https://wiki.qemu.org/index.php/SecurityProcess
+
+  * Libvirt https://libvirt.org/securityprocess.html
+
+  * FreeBSD https://www.freebsd.org/security/
+
+  * NetBSD http://www.netbsd.org/support/security/
+
+  * OpenBSD https://www.openbsd.org/security.html
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 02/17] SUPPORT.md: Add core functionality

[George Dunlap]

Core memory management and scheduling.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Changes since v2:
- s/Memory Ballooning/Dynamic memory control/;
- And add a description that mentions ballooning

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Dario Faggioli <dario.faggioli@citrix.com>
CC: Nathan Studer <nathan.studer@dornerworks.com>
---
 SUPPORT.md | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index e3d5d1de8d..934028074b 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -16,6 +16,68 @@ for the definitions of the support status levels etc.
 
 # Feature Support
 
+## Memory Management
+
+### Dynamic memory control
+
+    Status: Supported
+
+Allows a guest to add or remove memory after boot-time.
+This is typically done by a guest kernel agent known as a "balloon driver".
+
+## Resource Management
+
+### CPU Pools
+
+    Status: Supported
+
+Groups physical cpus into distinct groups called "cpupools",
+with each pool having the capability
+of using different schedulers and scheduling properties.
+
+### Credit Scheduler
+
+    Status: Supported
+
+A weighted proportional fair share virtual CPU scheduler.
+This is the default scheduler.
+
+### Credit2 Scheduler
+
+    Status: Supported
+
+A general purpose scheduler for Xen,
+designed with particular focus on fairness, responsiveness, and scalability
+
+### RTDS based Scheduler
+
+    Status: Experimental
+
+A soft real-time CPU scheduler
+built to provide guaranteed CPU capacity to guest VMs on SMP hosts
+
+### ARINC653 Scheduler
+
+    Status: Supported
+
+A periodically repeating fixed timeslice scheduler.
+Currently only single-vcpu domains are supported.
+
+### Null Scheduler
+
+    Status: Experimental
+
+A very simple, very static scheduling policy
+that always schedules the same vCPU(s) on the same pCPU(s).
+It is designed for maximum determinism and minimum overhead
+on embedded platforms.
+
+### NUMA scheduler affinity
+
+    Status, x86: Supported
+
+Enables NUMA aware scheduling in Xen
+
 # Format and definitions
 
 This file contains prose, and machine-readable fragments.
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 03/17] SUPPORT.md: Add some x86 features

[George Dunlap]

Including host architecture support and guest types.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Changes since v2:
- No Host ACPI listing for PVH dom0
- Add IOMMU entries for AMD and Intel

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
CC: Roger Pau Monne <roger.pau@citrix.com>
---
 SUPPORT.md | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index 934028074b..a4cf2da50d 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -16,6 +16,63 @@ for the definitions of the support status levels etc.
 
 # Feature Support
 
+## Host Architecture
+
+### x86-64
+
+    Status: Supported
+
+## Host hardware support
+
+### Physical CPU Hotplug
+
+    Status, x86: Supported
+
+### Physical Memory Hotplug
+
+    Status, x86: Supported
+
+### Host ACPI (via Domain 0)
+
+    Status, x86 PV: Supported
+
+### x86/Intel Platform QoS Technologies
+
+    Status: Tech Preview
+
+### IOMMU
+
+    Status, AMD IOMMU: Supported
+    Status, Intel VT-d: Supported
+
+## Guest Type
+
+### x86/PV
+
+    Status: Supported
+
+Traditional Xen PV guest
+
+No hardware requirements
+
+### x86/HVM
+
+    Status: Supported
+
+Fully virtualised guest using hardware virtualisation extensions
+
+Requires hardware virtualisation support (Intel VMX / AMD SVM)
+
+### x86/PVH guest
+
+    Status: Supported
+
+PVH is a next-generation paravirtualized mode 
+designed to take advantage of hardware virtualization support when possible.
+During development this was sometimes called HVMLite or PVHv2.
+
+Requires hardware virtualisation support (Intel VMX / AMD SVM)
+
 ## Memory Management
 
 ### Dynamic memory control
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 04/17] SUPPORT.md: Add core ARM features

[George Dunlap]

Hardware support and guest type.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Changes since v2:
- Moved SMMUv* into generic IOMMU section

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
CC: Julien Grall <julien.grall@arm.com>
---
 SUPPORT.md | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index a4cf2da50d..5945ab4926 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -22,6 +22,14 @@ for the definitions of the support status levels etc.
 
     Status: Supported
 
+### ARM v7 + Virtualization Extensions
+
+    Status: Supported
+
+### ARM v8
+
+    Status: Supported
+
 ## Host hardware support
 
 ### Physical CPU Hotplug
@@ -35,6 +43,7 @@ for the definitions of the support status levels etc.
 ### Host ACPI (via Domain 0)
 
     Status, x86 PV: Supported
+    Status, ARM: Experimental
 
 ### x86/Intel Platform QoS Technologies
 
@@ -44,6 +53,14 @@ for the definitions of the support status levels etc.
 
     Status, AMD IOMMU: Supported
     Status, Intel VT-d: Supported
+    Status, ARM SMMUv1: Supported
+    Status, ARM SMMUv2: Supported
+
+### ARM/GICv3 ITS
+
+    Status: Experimental
+
+Extension to the GICv3 interrupt controller to support MSI.
 
 ## Guest Type
 
@@ -67,12 +84,18 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM)
 
     Status: Supported
 
-PVH is a next-generation paravirtualized mode 
+PVH is a next-generation paravirtualized mode
 designed to take advantage of hardware virtualization support when possible.
 During development this was sometimes called HVMLite or PVHv2.
 
 Requires hardware virtualisation support (Intel VMX / AMD SVM)
 
+### ARM guest
+
+    Status: Supported
+
+ARM only has one guest type at the moment
+
 ## Memory Management
 
 ### Dynamic memory control
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 05/17] SUPPORT.md: Toolstack core

[George Dunlap]

For now only include xl-specific features, or interaction with the
system.  Feature support matrix will be added when features are
mentioned.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
---
 SUPPORT.md | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index 5945ab4926..df429cb3c4 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -96,6 +96,44 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM)
 
 ARM only has one guest type at the moment
 
+## Toolstack
+
+### xl
+
+    Status: Supported
+
+### Direct-boot kernel image format
+
+    Supported, x86: bzImage
+    Supported, ARM32: zImage
+    Supported, ARM64: Image
+
+Format which the toolstack accept for direct-boot kernels
+
+### systemd support for xl
+
+    Status: Supported
+
+### JSON output support for xl
+
+    Status: Experimental
+
+Output of information in machine-parseable JSON format
+
+### Open vSwitch integration for xl
+
+    Status, Linux: Supported
+
+### Virtual cpu hotplug
+
+    Status: Supported
+
+## Toolstack/3rd party
+
+### libvirt driver for xl
+
+    Status: Supported, Security support external
+
 ## Memory Management
 
 ### Dynamic memory control
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 06/17] SUPPORT.md: Add scalability features

[George Dunlap]

Superpage support and PVHVM.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Changes since v2:
- Reworked superpage section

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
CC: Julien Grall <julien.grall@arm.com>
---
 SUPPORT.md | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index df429cb3c4..dd3632b913 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -196,6 +196,33 @@ on embedded platforms.
 
 Enables NUMA aware scheduling in Xen
 
+## Scalability
+
+### Super page support
+
+    Status, x86 HVM/PVH, HAP: Supported
+    Status, x86 HVM/PVH, Shadow, 2MiB: Supported
+    Status, ARM: Supported
+
+NB that this refers to the ability of guests
+to have higher-level page table entries point directly to memory,
+improving TLB performance.
+On ARM, and on x86 in HAP mode,
+the guest has whatever support is enabled by the hardware.
+On x86 in shadow mode, only 2MiB (L2) superpages are available;
+furthermore, they do not have the performance characteristics of hardware superpages.
+
+Also note is feature independent of the ARM "page granularity" feature (see below).
+
+### x86/PVHVM
+
+    Status: Supported
+
+This is a useful label for a set of hypervisor features
+which add paravirtualized functionality to HVM guests
+for improved performance and scalability.
+This includes exposing event channels to HVM guests.
+
 # Format and definitions
 
 This file contains prose, and machine-readable fragments.
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 07/17] SUPPORT.md: Add virtual devices common to ARM and x86

[George Dunlap]

Mostly PV protocols.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Changes since v2:
- Define "having xl support" as a requirement for Tech Preview and Supported
- ...and remove backend from xl support section
- Add OpenBSD blkback
- Fix Linux backend names
- Remove non-existent implementation (PV USB Linux)
- Remove support for PV keyboard in Windows (Fix in qemu tree didn't make it)

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
CC: Roger Pau Monne <roger.pau@citrix.com>
CC: Anthony Perard <anthony.perard@citrix.com>
CC: Paul Durrant <paul.durrant@citrix.com>
CC: Julien Grall <julien.grall@arm.com>
---
 SUPPORT.md | 150 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 150 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index dd3632b913..96c381fb55 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -128,6 +128,10 @@ Output of information in machine-parseable JSON format
 
     Status: Supported
 
+### QEMU backend hotplugging for xl
+
+    Status: Supported
+
 ## Toolstack/3rd party
 
 ### libvirt driver for xl
@@ -223,6 +227,152 @@ which add paravirtualized functionality to HVM guests
 for improved performance and scalability.
 This includes exposing event channels to HVM guests.
 
+## Virtual driver support, guest side
+
+### Blkfront
+
+    Status, Linux: Supported
+    Status, FreeBSD: Supported, Security support external
+    Status, NetBSD: Supported, Security support external
+    Status, OpenBSD: Supported, Security support external
+    Status, Windows: Supported
+
+Guest-side driver capable of speaking the Xen PV block protocol
+
+### Netfront
+
+    Status, Linux: Supported
+    States, Windows: Supported
+    Status, FreeBSD: Supported, Security support external
+    Status, NetBSD: Supported, Security support external
+    Status, OpenBSD: Supported, Security support external
+
+Guest-side driver capable of speaking the Xen PV networking protocol
+
+### PV Framebuffer (frontend)
+
+    Status, Linux (xen-fbfront): Supported
+
+Guest-side driver capable of speaking the Xen PV Framebuffer protocol
+
+### PV Console (frontend)
+
+    Status, Linux (hvc_xen): Supported
+    Status, Windows: Supported
+    Status, FreeBSD: Supported, Security support external
+    Status, NetBSD: Supported, Security support external
+
+Guest-side driver capable of speaking the Xen PV console protocol
+
+### PV keyboard (frontend)
+
+    Status, Linux (xen-kbdfront): Supported
+
+Guest-side driver capable of speaking the Xen PV keyboard protocol
+
+### PV USB (frontend)
+
+    Status, Linux: Supported
+
+### PV SCSI protocol (frontend)
+
+    Status, Linux: Supported, with caveats
+
+NB that while the PV SCSI backend is in Linux and tested regularly,
+there is currently no xl support.
+
+### PV TPM (frontend)
+
+    Status, Linux (xen-tpmfront): Tech Preview
+
+Guest-side driver capable of speaking the Xen PV TPM protocol
+
+### PV 9pfs frontend
+
+    Status, Linux: Tech Preview
+
+Guest-side driver capable of speaking the Xen 9pfs protocol
+
+### PVCalls (frontend)
+
+    Status, Linux: Tech Preview
+
+Guest-side driver capable of making pv system calls
+
+## Virtual device support, host side
+
+For host-side virtual device support,
+"Supported" and "Tech preview" include xl/libxl support
+unless otherwise noted.
+
+### Blkback
+
+    Status, Linux (xen-blkback): Supported
+    Status, FreeBSD (blkback): Supported, Security support external
+    Status, NetBSD (xbdback): Supported, security support external
+    Status, QEMU (xen_disk): Supported
+    Status, Blktap2: Deprecated
+
+Host-side implementations of the Xen PV block protocol
+
+### Netback
+
+    Status, Linux (xen-netback): Supported
+    Status, FreeBSD (netback): Supported, Security support external
+    Status, NetBSD (xennetback): Supported, Security support external
+
+Host-side implementations of Xen PV network protocol
+
+### PV Framebuffer (backend)
+
+    Status, QEMU: Supported
+
+Host-side implementaiton of the Xen PV framebuffer protocol
+
+### PV Console (xenconsoled)
+
+    Status: Supported
+
+Host-side implementation of the Xen PV console protocol
+
+### PV keyboard (backend)
+
+    Status, QEMU: Supported
+
+Host-side implementation fo the Xen PV keyboard protocol
+
+### PV USB (backend)
+
+    Status, QEMU: Supported
+
+Host-side implementation of the Xen PV USB protocol
+
+### PV SCSI protocol (backend)
+
+    Status, Linux: Experimental
+
+NB that while the PV SCSI backend is in Linux and tested regularly,
+there is currently no xl support.
+
+### PV TPM (backend)
+
+    Status: Tech Preview
+
+### PV 9pfs (backend)
+
+    Status, QEMU: Tech Preview
+
+### PVCalls (backend)
+
+    Status, Linux: Experimental
+
+PVCalls backend has been checked into Linux,
+but has no xl support.
+
+### Online resize of virtual disks
+
+    Status: Supported
+
 # Format and definitions
 
 This file contains prose, and machine-readable fragments.
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 08/17] SUPPORT.md: Add x86-specific virtual hardware

[George Dunlap]

x86-specific virtual hardware provided by the hypervisor, toolstack,
or QEMU.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Changes since v2:
- Updated Nested PV / HVM sections
- Removed AVX section
- EFI -> OVMF

Changes since v1:
- Added emulated QEMU support, to replace docs/misc/qemu-xen-security.

Need to figure out what to do with the "backing storage image format"
section of that document.

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
CC: Roger Pau Monne <roger.pau@citrix.com>
CC: Anthony Perard <anthony.perard@citrix.com>
CC: Paul Durrant <paul.durrant@citrix.com>
---
 SUPPORT.md | 105 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 105 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index 96c381fb55..98ed18098a 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -373,6 +373,111 @@ but has no xl support.
 
     Status: Supported
 
+## Virtual Hardware, Hypervisor
+
+### x86/Nested PV
+
+    Status, x86 Xen HVM: Tech Preview
+
+This means running a Xen hypervisor inside an HVM domain on a Xen system,
+with support for PV L2 guests only
+(i.e., hardware virtualization extensions not provided
+to the guest).
+
+This works, but has performance limitations
+because the L1 dom0 can only access emulated L1 devices.
+
+Xen may also run inside other hypervisors (KVM, Hyper-V, VMWare),
+but nobody has reported on performance.
+
+### x86/Nested HVM
+
+    Status, x86 HVM: Experimental
+
+This means providing hardware virtulatization support to guest VMs
+allowing, for instance, a nested Xen to support both PV and HVM guests.
+It also implies support for other hypervisors,
+such as KVM, Hyper-V, Bromium, and so on as guests.
+
+### vPMU
+
+    Status, x86: Supported, Not security supported
+
+Virtual Performance Management Unit for HVM guests
+
+Disabled by default (enable with hypervisor command line option).
+This feature is not security supported: see http://xenbits.xen.org/xsa/advisory-163.html
+
+## Virtual Hardware, QEMU
+
+These are devices available in HVM mode using a qemu devicemodel (the default).
+Note that other devices are available but not security supported.
+
+### x86/Emulated platform devices (QEMU):
+
+    Status, piix3: Supported
+
+### x86/Emulated network (QEMU):
+
+    Status, e1000: Supported
+    Status, rtl8193: Supported
+    Status, virtio-net: Supported
+
+### x86/Emulated storage (QEMU):
+
+    Status, piix3 ide: Supported
+    Status, ahci: Supported
+
+### x86/Emulated graphics (QEMU):
+
+    Status, cirrus-vga: Supported
+    Status, stgvga: Supported
+
+### x86/Emulated audio (QEMU):
+
+    Status, sb16: Supported
+    Status, es1370: Supported
+    Status, ac97: Supported
+
+### x86/Emulated input (QEMU):
+
+    Status, usbmouse: Supported
+    Status, usbtablet: Supported
+    Status, ps/2 keyboard: Supported
+    Status, ps/2 mouse: Supported
+
+### x86/Emulated serial card (QEMU):
+
+    Status, UART 16550A: Supported
+
+### x86/Host USB passthrough (QEMU):
+
+    Status: Supported, not security supported
+
+## Virtual Firmware
+
+### x86/HVM iPXE
+
+    Status: Supported, with caveats
+
+Booting a guest via PXE.
+PXE inherently places full trust of the guest in the network,
+and so should only be used
+when the guest network is under the same administrative control
+as the guest itself.
+
+### x86/HVM BIOS
+
+    Status: Supported
+
+Booting a guest via guest BIOS firmware
+
+### x86/HVM OVMF
+
+    Status: Supported
+
+OVMF firmware implements the UEFI boot protocol.
+
 # Format and definitions
 
 This file contains prose, and machine-readable fragments.
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 09/17] SUPPORT.md: Add ARM-specific virtual hardware

[George Dunlap]

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Changes since v2:
- Update "non-pci passthrough" section
- Add DT / ACPI sections

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
CC: Julien Grall <julien.grall@arm.com>
---
 SUPPORT.md | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index 98ed18098a..f357291e4e 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -408,6 +408,27 @@ Virtual Performance Management Unit for HVM guests
 Disabled by default (enable with hypervisor command line option).
 This feature is not security supported: see http://xenbits.xen.org/xsa/advisory-163.html
 
+### ARM/Non-PCI device passthrough
+
+    Status: Supported, not security supported
+
+Note that this still requires an IOMMU
+that covers the DMA of the device to be passed through.
+
+### ARM: 16K and 64K page granularity in guests
+
+    Status: Supported, with caveats
+
+No support for QEMU backends in a 16K or 64K domain.
+
+### ARM: Guest Devicetree support
+
+    Status: Supported
+
+### ARM: Guest ACPI support
+
+    Status: Supported
+
 ## Virtual Hardware, QEMU
 
 These are devices available in HVM mode using a qemu devicemodel (the default).
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 10/17] SUPPORT.md: Add Debugging, analysis, crash post-portem

[George Dunlap]

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Changes since v2:
- gdbsx -> not security suported
- Added host serial, host debug keys, and host sync_console entries

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
---
 SUPPORT.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index f357291e4e..ee069f8499 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -138,6 +138,64 @@ Output of information in machine-parseable JSON format
 
     Status: Supported, Security support external
 
+## Debugging, analysis, and crash post-mortem
+
+### Host serial console
+
+    Status, NS16550: Supported
+	Status, EHCI: Supported
+	Status, Cadence UART (ARM): Supported
+	Status, PL011 UART (ARM): Supported
+	Status, Exynos 4210 UART (ARM): Supported
+	Status, OMAP UART (ARM): Supported
+	Status, SCI(F) UART: Supported
+
+XXX Should NS16550 and EHCI be limited to x86?  Unlike the ARM
+entries, they don't depend on x86 being configured
+
+### Hypervisor 'debug keys'
+
+    Status: Supported, not security supported
+
+These are functions triggered either from the host serial console,
+or via the xl 'debug-keys' command,
+which cause Xen to dump various hypervisor state to the console.
+
+### Hypervisor synchronous console output (sync_console)
+
+    Status: Supported, not security supported
+
+Xen command-line flag to force synchronous console output.
+Useful for debugging, but not suitable for production environments
+due to incurred overhead.
+
+### gdbsx
+
+    Status, x86: Supported, not security supported
+
+Debugger to debug ELF guests
+
+### Soft-reset for PV guests
+
+    Status: Supported
+
+Soft-reset allows a new kernel to start 'from scratch' with a fresh VM state,
+but with all the memory from the previous state of the VM intact.
+This is primarily designed to allow "crash kernels",
+which can do core dumps of memory to help with debugging in the event of a crash.
+
+### xentrace
+
+    Status, x86: Supported
+
+Tool to capture Xen trace buffer data
+
+### gcov
+
+    Status: Supported, Not security supported
+
+Export hypervisor coverage data suitable for analysis by gcov or lcov.
+
 ## Memory Management
 
 ### Dynamic memory control
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 11/17] SUPPORT.md: Add 'easy' HA / FT features

[George Dunlap]

Migration being one of the key 'non-easy' ones to be added later.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes since v2:
- Capitalization error

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
---
 SUPPORT.md | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index ee069f8499..cc8b754749 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -285,6 +285,22 @@ which add paravirtualized functionality to HVM guests
 for improved performance and scalability.
 This includes exposing event channels to HVM guests.
 
+## High Availability and Fault Tolerance
+
+### Remus Fault Tolerance
+
+    Status: Experimental
+
+### COLO Manager
+
+    Status: Experimental
+
+### x86/vMCE
+
+    Status: Supported
+
+Forward Machine Check Exceptions to appropriate guests
+
 ## Virtual driver support, guest side
 
 ### Blkfront
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 12/17] SUPPORT.md: Add Security-releated features

[George Dunlap]

With the exception of driver domains, which depend on PCI passthrough,
and will be introduced later.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Changes since v2:
- Reference XSA-77 as well under the XSM & FLASK section

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
CC: Tamas K Lengyel <tamas.lengyel@zentific.com>
CC: Rich Persaud <persaur@gmail.com>
---
 SUPPORT.md | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index cc8b754749..2d4386ad68 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -447,6 +447,46 @@ but has no xl support.
 
     Status: Supported
 
+## Security
+
+### Device Model Stub Domains
+
+    Status: Supported
+
+### KCONFIG Expert
+
+    Status: Experimental
+
+### Live Patching
+
+    Status, x86: Supported
+    Status, ARM: Experimental
+
+Compile time disabled for ARM
+
+### Virtual Machine Introspection
+
+    Status, x86: Supported, not security supported
+
+### XSM & FLASK
+
+    Status: Experimental
+
+Compile time disabled.
+
+Also note that using XSM
+to delegate various domain control hypercalls
+to particular other domains, rather than only permitting use by dom0,
+is also specifically excluded from security support for many hypercalls.
+Please see XSA-77 for more details.
+
+### FLASK default policy
+
+    Status: Experimental
+
+The default policy includes FLASK labels and roles for a "typical" Xen-based system
+with dom0, driver domains, stub domains, domUs, and so on.
+
 ## Virtual Hardware, Hypervisor
 
 ### x86/Nested PV
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 13/17] SUPPORT.md: Add secondary memory management features

[George Dunlap]

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes since v2:
- Add PoD entry
- memsharing x86 -> experimental, ARM -> {}

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
CC: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
 SUPPORT.md | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index 2d4386ad68..63f6a6d127 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -205,6 +205,43 @@ Export hypervisor coverage data suitable for analysis by gcov or lcov.
 Allows a guest to add or remove memory after boot-time.
 This is typically done by a guest kernel agent known as a "balloon driver".
 
+### Populate-on-demand memory
+
+    Status, x86 HVM: Supported
+
+This is a mechanism that allows normal operating systems with only a balloon driver
+to boot with memory < maxmem.
+
+### Memory Sharing
+
+    Status, x86 HVM: Expermental
+
+Allow sharing of identical pages between guests
+
+### Memory Paging
+
+    Status, x86 HVM: Experimenal
+
+Allow pages belonging to guests to be paged to disk
+
+### Transcendent Memory
+
+    Status: Experimental
+
+Transcendent Memory (tmem) allows the creation of hypervisor memory pools
+which guests can use to store memory
+rather than caching in its own memory or swapping to disk.
+Having these in the hypervisor
+can allow more efficient aggregate use of memory across VMs.
+
+### Alternative p2m
+
+    Status, x86 HVM: Tech Preview
+    Status, ARM: Tech Preview
+
+Allows external monitoring of hypervisor memory
+by maintaining multiple physical to machine (p2m) memory mappings.
+
 ## Resource Management
 
 ### CPU Pools
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 14/17] SUPPORT.md: Add statement on PCI passthrough

[George Dunlap]

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Changes since v2:
- Separate PV and HVM passthrough (excluding PVH by implication)
- + not compatible with PoD
- 'will be' -> 'are'

NB that we don't seem to have the referenced file yet; left as a reference.

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
CC: Rich Persaud <persaur@gmail.com>
CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
CC: Christopher Clark <christopher.w.clark@gmail.com>
CC: James McKenzie <james.mckenzie@bromium.com>
---
 SUPPORT.md | 36 +++++++++++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 63f6a6d127..c8fec4daa8 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -486,9 +486,23 @@ but has no xl support.
 
 ## Security
 
+### Driver Domains
+
+    Status: Supported, with caveats
+
+"Driver domains" means allowing non-Domain 0 domains
+with access to physical devices to act as back-ends.
+
+See the appropriate "Device Passthrough" section
+for more information about security support.
+
 ### Device Model Stub Domains
 
-    Status: Supported
+    Status: Supported, with caveats
+
+Vulnerabilities of a device model stub domain
+to a hostile driver domain (either compromised or untrusted)
+are excluded from security support.
 
 ### KCONFIG Expert
 
@@ -559,6 +573,26 @@ Virtual Performance Management Unit for HVM guests
 Disabled by default (enable with hypervisor command line option).
 This feature is not security supported: see http://xenbits.xen.org/xsa/advisory-163.html
 
+### x86/PCI Device Passthrough
+
+    Status, x86 PV: Supported, with caveats
+    Status, x86 HVM: Supported, with caveats
+
+Only systems using IOMMUs are supported.
+
+Not compatible with migration, populate-on-demand, altp2m,
+introspection, memory sharing, or memory paging.
+
+Because of hardware limitations
+(affecting any operating system or hypervisor),
+it is generally not safe to use this feature
+to expose a physical device to completely untrusted guests.
+However, this feature can still confer significant security benefit
+when used to remove drivers and backends from domain 0
+(i.e., Driver Domains).
+
+XXX See docs/PCI-IOMMU-bugs.txt for more information.
+
 ### ARM/Non-PCI device passthrough
 
     Status: Supported, not security supported
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 15/17] SUPPORT.md: Add statement on migration RFC

[George Dunlap]

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Would someone be willing to take over this one?

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
CC: Roger Pau Monne <roger.pau@citrix.com>
CC: Anthony Perard <anthony.perard@citrix.com>
CC: Paul Durrant <paul.durrant@citrix.com>
CC: Julien Grall <julien.grall@arm.com>
---
 SUPPORT.md | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index c8fec4daa8..aa58fb0de3 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -324,6 +324,36 @@ This includes exposing event channels to HVM guests.
 
 ## High Availability and Fault Tolerance
 
+### Live Migration, Save & Restore
+
+    Status, x86: Supported, with caveats
+
+A number of features don't work with live migration / save / restore.  These include:
+ * PCI passthrough
+ * vNUMA
+ * Nested HVM
+
+XXX Need to check the following:
+
+ * Guest serial console
+ * Crash kernels
+ * Transcendent Memory
+ * Alternative p2m
+ * vMCE
+ * vPMU
+ * Intel Platform QoS
+ * Remus
+ * COLO
+ * PV protocols: Keyboard, PVUSB, PVSCSI, PVTPM, 9pfs, pvcalls?
+ * FlASK?
+ * CPU / memory hotplug?
+
+Additionally, if an HVM guest was booted with memory != maxmem,
+and the balloon driver hadn't hit the target before migration,
+the size of the guest on the far side might be unexpected.
+
+See docs/features/migration.pandoc for more details
+
 ### Remus Fault Tolerance
 
     Status: Experimental
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 16/17] SUPPORT.md: Add limits RFC

[George Dunlap]

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Changes since v2:
- Update memory limits for PV guests

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
---
 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,
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v3 17/17] SUPPORT.md: Miscellaneous additions

[George Dunlap]

Mostly as a placeholder for things not yet considered

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
 SUPPORT.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index 72be1414a1..08f3a808be 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -132,6 +132,8 @@ Fully virtualised guest using hardware virtualisation extensions
 
 Requires hardware virtualisation support (Intel VMX / AMD SVM)
 
+XXX Figure out of we need to add qemu-trad / qemu-upstream to this mix
+
 ### x86/PVH guest
 
     Status: Supported
-- 
2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v3 07/17] SUPPORT.md: Add virtual devices common to ARM and x86

[Paul Durrant]

> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@citrix.com]
> Sent: 22 November 2017 19:20
> To: xen-devel@lists.xenproject.org
> Cc: George Dunlap <George.Dunlap@citrix.com>; Ian Jackson
> <Ian.Jackson@citrix.com>; Wei Liu <wei.liu2@citrix.com>; Andrew Cooper
> <Andrew.Cooper3@citrix.com>; Jan Beulich <jbeulich@suse.com>; Stefano
> Stabellini <sstabellini@kernel.org>; Konrad Wilk <konrad.wilk@oracle.com>;
> Tim (Xen.org) <tim@xen.org>; Roger Pau Monne <roger.pau@citrix.com>;
> Anthony Perard <anthony.perard@citrix.com>; Paul Durrant
> <Paul.Durrant@citrix.com>; Julien Grall <julien.grall@arm.com>
> Subject: [PATCH v3 07/17] SUPPORT.md: Add virtual devices common to
> ARM and x86
> 
> Mostly PV protocols.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Reviewed-by: Paul Durrant <paul.durrant@citrix.com>

> ---
> Changes since v2:
> - Define "having xl support" as a requirement for Tech Preview and
> Supported
> - ...and remove backend from xl support section
> - Add OpenBSD blkback
> - Fix Linux backend names
> - Remove non-existent implementation (PV USB Linux)
> - Remove support for PV keyboard in Windows (Fix in qemu tree didn't make
> it)
> 
> CC: Ian Jackson <ian.jackson@citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Konrad Wilk <konrad.wilk@oracle.com>
> CC: Tim Deegan <tim@xen.org>
> CC: Roger Pau Monne <roger.pau@citrix.com>
> CC: Anthony Perard <anthony.perard@citrix.com>
> CC: Paul Durrant <paul.durrant@citrix.com>
> CC: Julien Grall <julien.grall@arm.com>
> ---
>  SUPPORT.md | 150
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++
>  1 file changed, 150 insertions(+)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index dd3632b913..96c381fb55 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -128,6 +128,10 @@ Output of information in machine-parseable JSON
> format
> 
>      Status: Supported
> 
> +### QEMU backend hotplugging for xl
> +
> +    Status: Supported
> +
>  ## Toolstack/3rd party
> 
>  ### libvirt driver for xl
> @@ -223,6 +227,152 @@ which add paravirtualized functionality to HVM
> guests
>  for improved performance and scalability.
>  This includes exposing event channels to HVM guests.
> 
> +## Virtual driver support, guest side
> +
> +### Blkfront
> +
> +    Status, Linux: Supported
> +    Status, FreeBSD: Supported, Security support external
> +    Status, NetBSD: Supported, Security support external
> +    Status, OpenBSD: Supported, Security support external
> +    Status, Windows: Supported
> +
> +Guest-side driver capable of speaking the Xen PV block protocol
> +
> +### Netfront
> +
> +    Status, Linux: Supported
> +    States, Windows: Supported
> +    Status, FreeBSD: Supported, Security support external
> +    Status, NetBSD: Supported, Security support external
> +    Status, OpenBSD: Supported, Security support external
> +
> +Guest-side driver capable of speaking the Xen PV networking protocol
> +
> +### PV Framebuffer (frontend)
> +
> +    Status, Linux (xen-fbfront): Supported
> +
> +Guest-side driver capable of speaking the Xen PV Framebuffer protocol
> +
> +### PV Console (frontend)
> +
> +    Status, Linux (hvc_xen): Supported
> +    Status, Windows: Supported
> +    Status, FreeBSD: Supported, Security support external
> +    Status, NetBSD: Supported, Security support external
> +
> +Guest-side driver capable of speaking the Xen PV console protocol
> +
> +### PV keyboard (frontend)
> +
> +    Status, Linux (xen-kbdfront): Supported
> +
> +Guest-side driver capable of speaking the Xen PV keyboard protocol
> +
> +### PV USB (frontend)
> +
> +    Status, Linux: Supported
> +
> +### PV SCSI protocol (frontend)
> +
> +    Status, Linux: Supported, with caveats
> +
> +NB that while the PV SCSI backend is in Linux and tested regularly,
> +there is currently no xl support.
> +
> +### PV TPM (frontend)
> +
> +    Status, Linux (xen-tpmfront): Tech Preview
> +
> +Guest-side driver capable of speaking the Xen PV TPM protocol
> +
> +### PV 9pfs frontend
> +
> +    Status, Linux: Tech Preview
> +
> +Guest-side driver capable of speaking the Xen 9pfs protocol
> +
> +### PVCalls (frontend)
> +
> +    Status, Linux: Tech Preview
> +
> +Guest-side driver capable of making pv system calls
> +
> +## Virtual device support, host side
> +
> +For host-side virtual device support,
> +"Supported" and "Tech preview" include xl/libxl support
> +unless otherwise noted.
> +
> +### Blkback
> +
> +    Status, Linux (xen-blkback): Supported
> +    Status, FreeBSD (blkback): Supported, Security support external
> +    Status, NetBSD (xbdback): Supported, security support external
> +    Status, QEMU (xen_disk): Supported
> +    Status, Blktap2: Deprecated
> +
> +Host-side implementations of the Xen PV block protocol
> +
> +### Netback
> +
> +    Status, Linux (xen-netback): Supported
> +    Status, FreeBSD (netback): Supported, Security support external
> +    Status, NetBSD (xennetback): Supported, Security support external
> +
> +Host-side implementations of Xen PV network protocol
> +
> +### PV Framebuffer (backend)
> +
> +    Status, QEMU: Supported
> +
> +Host-side implementaiton of the Xen PV framebuffer protocol
> +
> +### PV Console (xenconsoled)
> +
> +    Status: Supported
> +
> +Host-side implementation of the Xen PV console protocol
> +
> +### PV keyboard (backend)
> +
> +    Status, QEMU: Supported
> +
> +Host-side implementation fo the Xen PV keyboard protocol
> +
> +### PV USB (backend)
> +
> +    Status, QEMU: Supported
> +
> +Host-side implementation of the Xen PV USB protocol
> +
> +### PV SCSI protocol (backend)
> +
> +    Status, Linux: Experimental
> +
> +NB that while the PV SCSI backend is in Linux and tested regularly,
> +there is currently no xl support.
> +
> +### PV TPM (backend)
> +
> +    Status: Tech Preview
> +
> +### PV 9pfs (backend)
> +
> +    Status, QEMU: Tech Preview
> +
> +### PVCalls (backend)
> +
> +    Status, Linux: Experimental
> +
> +PVCalls backend has been checked into Linux,
> +but has no xl support.
> +
> +### Online resize of virtual disks
> +
> +    Status: Supported
> +
>  # Format and definitions
> 
>  This file contains prose, and machine-readable fragments.
> --
> 2.15.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 02/17] SUPPORT.md: Add core functionality

[Jan Beulich]

>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
> Core memory management and scheduling.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 03/17] SUPPORT.md: Add some x86 features

[Jan Beulich]

>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
> Including host architecture support and guest types.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 06/17] SUPPORT.md: Add scalability features

[Jan Beulich]

>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
> Superpage support and PVHVM.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
with one remark:

> +## Scalability
> +
> +### Super page support
> +
> +    Status, x86 HVM/PVH, HAP: Supported
> +    Status, x86 HVM/PVH, Shadow, 2MiB: Supported
> +    Status, ARM: Supported
> +
> +NB that this refers to the ability of guests
> +to have higher-level page table entries point directly to memory,
> +improving TLB performance.
> +On ARM, and on x86 in HAP mode,
> +the guest has whatever support is enabled by the hardware.
> +On x86 in shadow mode, only 2MiB (L2) superpages are available;
> +furthermore, they do not have the performance characteristics of hardware superpages.
> +
> +Also note is feature independent of the ARM "page granularity" feature (see below).

Earlier lines in this block suggest you've tried to honor a certain
line length limit, while the two last non-empty ones clearly go
beyond 80 columns.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 07/17] SUPPORT.md: Add virtual devices common to ARM and x86

[Jan Beulich]

>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
> Mostly PV protocols.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
with a couple of remarks.

> @@ -223,6 +227,152 @@ which add paravirtualized functionality to HVM guests
>  for improved performance and scalability.
>  This includes exposing event channels to HVM guests.
>  
> +## Virtual driver support, guest side

With "guest side" here, ...

> +### Blkfront
> +
> +    Status, Linux: Supported
> +    Status, FreeBSD: Supported, Security support external
> +    Status, NetBSD: Supported, Security support external
> +    Status, OpenBSD: Supported, Security support external
> +    Status, Windows: Supported
> +
> +Guest-side driver capable of speaking the Xen PV block protocol
> +
> +### Netfront
> +
> +    Status, Linux: Supported
> +    States, Windows: Supported
> +    Status, FreeBSD: Supported, Security support external
> +    Status, NetBSD: Supported, Security support external
> +    Status, OpenBSD: Supported, Security support external
> +
> +Guest-side driver capable of speaking the Xen PV networking protocol
> +
> +### PV Framebuffer (frontend)

... is "(frontend)" here (also on entries further down) really useful?
Same for "host side" and "(backend)" then further down.

Also would it perhaps make sense to sort multiple OS entries by
some criteria (name, support status, ...)? Just like we ask that
new source files have #include-s sorted, this helps reduce patch
conflicts when otherwise everyone adds to the end of such lists.

> +### PV SCSI protocol (frontend)
> +
> +    Status, Linux: Supported, with caveats
> +
> +NB that while the PV SCSI backend is in Linux and tested regularly,
> +there is currently no xl support.

Perhaps a copy-and-paste mistake saying "backend" here?

> +### PV Framebuffer (backend)
> +
> +    Status, QEMU: Supported
> +
> +Host-side implementaiton of the Xen PV framebuffer protocol

implementation

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 08/17] SUPPORT.md: Add x86-specific virtual hardware

[Jan Beulich]

>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
> x86-specific virtual hardware provided by the hypervisor, toolstack,
> or QEMU.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Non-QEMU parts
Acked-by: Jan Beulich <jbeulich@suse.com>
with one typo preferably corrected:

> +### x86/Nested HVM
> +
> +    Status, x86 HVM: Experimental
> +
> +This means providing hardware virtulatization support to guest VMs

virtualization

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 04/17] SUPPORT.md: Add core ARM features

[Julien Grall]

Hi George,

On 22/11/17 19:20, George Dunlap wrote:
> Hardware support and guest type.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> ---
> Changes since v2:
> - Moved SMMUv* into generic IOMMU section
> 
> CC: Ian Jackson <ian.jackson@citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Konrad Wilk <konrad.wilk@oracle.com>
> CC: Tim Deegan <tim@xen.org>
> CC: Julien Grall <julien.grall@arm.com>
> ---
>   SUPPORT.md | 25 ++++++++++++++++++++++++-
>   1 file changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index a4cf2da50d..5945ab4926 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -22,6 +22,14 @@ for the definitions of the support status levels etc.
>   
>       Status: Supported
>   
> +### ARM v7 + Virtualization Extensions
> +
> +    Status: Supported
> +
> +### ARM v8
> +
> +    Status: Supported
> +
>   ## Host hardware support
>   
>   ### Physical CPU Hotplug
> @@ -35,6 +43,7 @@ for the definitions of the support status levels etc.
>   ### Host ACPI (via Domain 0)
>   
>       Status, x86 PV: Supported
> +    Status, ARM: Experimental
>   
>   ### x86/Intel Platform QoS Technologies
>   
> @@ -44,6 +53,14 @@ for the definitions of the support status levels etc.
>   
>       Status, AMD IOMMU: Supported
>       Status, Intel VT-d: Supported
> +    Status, ARM SMMUv1: Supported
> +    Status, ARM SMMUv2: Supported
> +
> +### ARM/GICv3 ITS
> +
> +    Status: Experimental
> +
> +Extension to the GICv3 interrupt controller to support MSI.
>   
>   ## Guest Type
>   
> @@ -67,12 +84,18 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM)
>   
>       Status: Supported
>   
> -PVH is a next-generation paravirtualized mode
> +PVH is a next-generation paravirtualized mode

I am not sure to see the difference between the 2 lines. Is it intented?

The rest looks good.

Cheers,

>   designed to take advantage of hardware virtualization support when possible.
>   During development this was sometimes called HVMLite or PVHv2.
>   
>   Requires hardware virtualisation support (Intel VMX / AMD SVM)
>   
> +### ARM guest
> +
> +    Status: Supported
> +
> +ARM only has one guest type at the moment
> +
>   ## Memory Management
>   
>   ### Dynamic memory control
> 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 06/17] SUPPORT.md: Add scalability features

[Julien Grall]

Hi George,

On 22/11/17 19:20, George Dunlap wrote:
> Superpage support and PVHVM.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> ---
> Changes since v2:
> - Reworked superpage section
> 
> CC: Ian Jackson <ian.jackson@citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Konrad Wilk <konrad.wilk@oracle.com>
> CC: Tim Deegan <tim@xen.org>
> CC: Julien Grall <julien.grall@arm.com>

For the ARM bits:

Acked-by: Julien Grall <julien.gralL@linaro.org>

Cheers,

> ---
>   SUPPORT.md | 27 +++++++++++++++++++++++++++
>   1 file changed, 27 insertions(+)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index df429cb3c4..dd3632b913 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -196,6 +196,33 @@ on embedded platforms.
>   
>   Enables NUMA aware scheduling in Xen
>   
> +## Scalability
> +
> +### Super page support
> +
> +    Status, x86 HVM/PVH, HAP: Supported
> +    Status, x86 HVM/PVH, Shadow, 2MiB: Supported
> +    Status, ARM: Supported
> +
> +NB that this refers to the ability of guests
> +to have higher-level page table entries point directly to memory,
> +improving TLB performance.
> +On ARM, and on x86 in HAP mode,
> +the guest has whatever support is enabled by the hardware.
> +On x86 in shadow mode, only 2MiB (L2) superpages are available;
> +furthermore, they do not have the performance characteristics of hardware superpages.
> +
> +Also note is feature independent of the ARM "page granularity" feature (see below).
> +
> +### x86/PVHVM
> +
> +    Status: Supported
> +
> +This is a useful label for a set of hypervisor features
> +which add paravirtualized functionality to HVM guests
> +for improved performance and scalability.
> +This includes exposing event channels to HVM guests.
> +
>   # Format and definitions
>   
>   This file contains prose, and machine-readable fragments.
> 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 04/17] SUPPORT.md: Add core ARM features

[George Dunlap]

On 11/23/2017 11:11 AM, Julien Grall wrote:
> Hi George,
> 
> On 22/11/17 19:20, George Dunlap wrote:
>> Hardware support and guest type.
>>
>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>> ---
>> Changes since v2:
>> - Moved SMMUv* into generic IOMMU section
>>
>> CC: Ian Jackson <ian.jackson@citrix.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
>> CC: Jan Beulich <jbeulich@suse.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Konrad Wilk <konrad.wilk@oracle.com>
>> CC: Tim Deegan <tim@xen.org>
>> CC: Julien Grall <julien.grall@arm.com>
>> ---
>>   SUPPORT.md | 25 ++++++++++++++++++++++++-
>>   1 file changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/SUPPORT.md b/SUPPORT.md
>> index a4cf2da50d..5945ab4926 100644
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -22,6 +22,14 @@ for the definitions of the support status levels etc.
>>         Status: Supported
>>   +### ARM v7 + Virtualization Extensions
>> +
>> +    Status: Supported
>> +
>> +### ARM v8
>> +
>> +    Status: Supported
>> +
>>   ## Host hardware support
>>     ### Physical CPU Hotplug
>> @@ -35,6 +43,7 @@ for the definitions of the support status levels etc.
>>   ### Host ACPI (via Domain 0)
>>         Status, x86 PV: Supported
>> +    Status, ARM: Experimental
>>     ### x86/Intel Platform QoS Technologies
>>   @@ -44,6 +53,14 @@ for the definitions of the support status levels
>> etc.
>>         Status, AMD IOMMU: Supported
>>       Status, Intel VT-d: Supported
>> +    Status, ARM SMMUv1: Supported
>> +    Status, ARM SMMUv2: Supported
>> +
>> +### ARM/GICv3 ITS
>> +
>> +    Status: Experimental
>> +
>> +Extension to the GICv3 interrupt controller to support MSI.
>>     ## Guest Type
>>   @@ -67,12 +84,18 @@ Requires hardware virtualisation support (Intel
>> VMX / AMD SVM)
>>         Status: Supported
>>   -PVH is a next-generation paravirtualized mode
>> +PVH is a next-generation paravirtualized mode
> 
> I am not sure to see the difference between the 2 lines. Is it intented?

The difference is the whitespace at the end -- this change should have
been made in the previous patch instead.

> The rest looks good.

Thanks. With that moved, can it have your Ack?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 09/17] SUPPORT.md: Add ARM-specific virtual hardware

[Julien Grall]

Hi George,

On 22/11/17 19:20, George Dunlap wrote:
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> ---
> Changes since v2:
> - Update "non-pci passthrough" section
> - Add DT / ACPI sections
> 
> CC: Ian Jackson <ian.jackson@citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Konrad Wilk <konrad.wilk@oracle.com>
> CC: Tim Deegan <tim@xen.org>
> CC: Julien Grall <julien.grall@arm.com>
> ---
>   SUPPORT.md | 21 +++++++++++++++++++++
>   1 file changed, 21 insertions(+)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 98ed18098a..f357291e4e 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -408,6 +408,27 @@ Virtual Performance Management Unit for HVM guests
>   Disabled by default (enable with hypervisor command line option).
>   This feature is not security supported: see http://xenbits.xen.org/xsa/advisory-163.html
>   
> +### ARM/Non-PCI device passthrough
> +
> +    Status: Supported, not security supported
> +
> +Note that this still requires an IOMMU
> +that covers the DMA of the device to be passed through.
> +
> +### ARM: 16K and 64K page granularity in guests
> +
> +    Status: Supported, with caveats
> +
> +No support for QEMU backends in a 16K or 64K domain.
> +
> +### ARM: Guest Devicetree support

NIT: s/Devicetree/Device Tree/

Acked-by: Julien Grall <julien.grall@linaro.org>

Cheers,

> +
> +    Status: Supported
> +
> +### ARM: Guest ACPI support
> +
> +    Status: Supported
> +
>   ## Virtual Hardware, QEMU
>   
>   These are devices available in HVM mode using a qemu devicemodel (the default).
> 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 10/17] SUPPORT.md: Add Debugging, analysis, crash post-portem

[Jan Beulich]

>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
> +## Debugging, analysis, and crash post-mortem
> +
> +### Host serial console
> +
> +    Status, NS16550: Supported
> +	Status, EHCI: Supported

Inconsistent indentation.

> +	Status, Cadence UART (ARM): Supported
> +	Status, PL011 UART (ARM): Supported
> +	Status, Exynos 4210 UART (ARM): Supported
> +	Status, OMAP UART (ARM): Supported
> +	Status, SCI(F) UART: Supported
> +
> +XXX Should NS16550 and EHCI be limited to x86?  Unlike the ARM
> +entries, they don't depend on x86 being configured

ns16550 ought to be usable everywhere. EHCI is x86-only
anyway (presumably first of all because it takes PCI as a prereq)
 - there's a "select" needed, which only x86 has. In the end I
view the ARM way of expressing things wrong there: I think all
"HAS_*" items would better require "select"s (unless, like for
ns16550, they're there sort of for documentation / consistency
purpose only).

With this XXX dropped (and with or without adding (x86) to
EHCI)
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 04/17] SUPPORT.md: Add core ARM features

[Julien Grall]

On 23/11/17 11:13, George Dunlap wrote:
> On 11/23/2017 11:11 AM, Julien Grall wrote:
>> The rest looks good.
> 
> Thanks. With that moved, can it have your Ack?

Sure

Acked-by: Julien Grall <julien.grall@linaro.org>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 12/17] SUPPORT.md: Add Security-releated features

[Jan Beulich]

>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
> +### Live Patching
> +
> +    Status, x86: Supported
> +    Status, ARM: Experimental
> +
> +Compile time disabled for ARM

"... by default"?

> +### XSM & FLASK
> +
> +    Status: Experimental
> +
> +Compile time disabled.

Same here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 14/17] SUPPORT.md: Add statement on PCI passthrough

[Jan Beulich]

>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>

With the XXX suitably addressed
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 15/17] SUPPORT.md: Add statement on migration RFC

[Jan Beulich]

>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
> +XXX Need to check the following:
> +
> + * Guest serial console
> + * Crash kernels
> + * Transcendent Memory
> + * Alternative p2m
> + * vMCE

vMCE has provisions for migration (albeit there has been breakage
here more than once in the past, iirc).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 16/17] SUPPORT.md: Add limits RFC

[Jan Beulich]

>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
> +### 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.

While certainly harder to grok for the reader, I think we need to be
precise here: The factor isn't the amount of memory, but the
addresses at which it surfaces. Host memory must not extend
beyond the 168MiB boundary for that to also be the limit for
32-bit PV guests.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 06/17] SUPPORT.md: Add scalability features

[George Dunlap]

On 11/23/2017 10:50 AM, Jan Beulich wrote:
>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>> Superpage support and PVHVM.
>>
>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> with one remark:
> 
>> +## Scalability
>> +
>> +### Super page support
>> +
>> +    Status, x86 HVM/PVH, HAP: Supported
>> +    Status, x86 HVM/PVH, Shadow, 2MiB: Supported
>> +    Status, ARM: Supported
>> +
>> +NB that this refers to the ability of guests
>> +to have higher-level page table entries point directly to memory,
>> +improving TLB performance.
>> +On ARM, and on x86 in HAP mode,
>> +the guest has whatever support is enabled by the hardware.
>> +On x86 in shadow mode, only 2MiB (L2) superpages are available;
>> +furthermore, they do not have the performance characteristics of hardware superpages.
>> +
>> +Also note is feature independent of the ARM "page granularity" feature (see below).
> 
> Earlier lines in this block suggest you've tried to honor a certain
> line length limit, while the two last non-empty ones clearly go
> beyond 80 columns.

Yes, the "semantic newlines" is a bit ambiguous: It rather implies that
we expect people to use a processed version of this file (in which case
the line length isn't as important).

But I'll trim these down anyway.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 07/17] SUPPORT.md: Add virtual devices common to ARM and x86

[George Dunlap]

On 11/23/2017 10:59 AM, Jan Beulich wrote:
>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>> Mostly PV protocols.
>>
>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> with a couple of remarks.
> 
>> @@ -223,6 +227,152 @@ which add paravirtualized functionality to HVM guests
>>  for improved performance and scalability.
>>  This includes exposing event channels to HVM guests.
>>  
>> +## Virtual driver support, guest side
> 
> With "guest side" here, ...
> 
>> +### Blkfront
>> +
>> +    Status, Linux: Supported
>> +    Status, FreeBSD: Supported, Security support external
>> +    Status, NetBSD: Supported, Security support external
>> +    Status, OpenBSD: Supported, Security support external
>> +    Status, Windows: Supported
>> +
>> +Guest-side driver capable of speaking the Xen PV block protocol
>> +
>> +### Netfront
>> +
>> +    Status, Linux: Supported
>> +    States, Windows: Supported
>> +    Status, FreeBSD: Supported, Security support external
>> +    Status, NetBSD: Supported, Security support external
>> +    Status, OpenBSD: Supported, Security support external
>> +
>> +Guest-side driver capable of speaking the Xen PV networking protocol
>> +
>> +### PV Framebuffer (frontend)
> 
> ... is "(frontend)" here (also on entries further down) really useful?
> Same for "host side" and "(backend)" then further down.

These were specifically requested, because the frontend and backend
entries end up looking very similar, and it's difficult to tell which
section you're in.

> Also would it perhaps make sense to sort multiple OS entries by
> some criteria (name, support status, ...)? Just like we ask that
> new source files have #include-s sorted, this helps reduce patch
> conflicts when otherwise everyone adds to the end of such lists.

Probably, yes.  I generally tried to rank them in order of {Linux, qemu,
*BSD, Windows}, on the grounds that Linux and QEMU are generally
developed by the "core" team (and have the most testing and attention),
and we should favor fellow open-source project (like the BSDs) over
proprietary systems (i.e., Windows).  But I don't seem to have been very
consistent in that.

>> +### PV SCSI protocol (frontend)
>> +
>> +    Status, Linux: Supported, with caveats
>> +
>> +NB that while the PV SCSI backend is in Linux and tested regularly,
>> +there is currently no xl support.
> 
> Perhaps a copy-and-paste mistake saying "backend" here?

Good catch, thanks.

>> +### PV Framebuffer (backend)
>> +
>> +    Status, QEMU: Supported
>> +
>> +Host-side implementaiton of the Xen PV framebuffer protocol
> 
> implementation

Ack

> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 10/17] SUPPORT.md: Add Debugging, analysis, crash post-portem

[George Dunlap]

On 11/23/2017 11:15 AM, Jan Beulich wrote:
>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>> +## Debugging, analysis, and crash post-mortem
>> +
>> +### Host serial console
>> +
>> +    Status, NS16550: Supported
>> +	Status, EHCI: Supported
> 
> Inconsistent indentation.

And I was so sure I'd checked all those. :-/

> 
>> +	Status, Cadence UART (ARM): Supported
>> +	Status, PL011 UART (ARM): Supported
>> +	Status, Exynos 4210 UART (ARM): Supported
>> +	Status, OMAP UART (ARM): Supported
>> +	Status, SCI(F) UART: Supported
>> +
>> +XXX Should NS16550 and EHCI be limited to x86?  Unlike the ARM
>> +entries, they don't depend on x86 being configured
> 
> ns16550 ought to be usable everywhere. EHCI is x86-only
> anyway (presumably first of all because it takes PCI as a prereq)

But that's just an accident at the moment; I thought there were plans at
some point for ARM servers to have PCI, weren't there?

I'll probably just leave this as it is, unless someone thinks differently.

> With this XXX dropped (and with or without adding (x86) to
> EHCI)
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks,
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 12/17] SUPPORT.md: Add Security-releated features

[George Dunlap]

On 11/23/2017 11:16 AM, Jan Beulich wrote:
>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>> +### Live Patching
>> +
>> +    Status, x86: Supported
>> +    Status, ARM: Experimental
>> +
>> +Compile time disabled for ARM
> 
> "... by default"?
> 
>> +### XSM & FLASK
>> +
>> +    Status: Experimental
>> +
>> +Compile time disabled.
> 
> Same here.

Ack.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 16/17] SUPPORT.md: Add limits RFC

[George Dunlap]

On 11/23/2017 11:21 AM, Jan Beulich wrote:
>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>> +### 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.
> 
> While certainly harder to grok for the reader, I think we need to be
> precise here: The factor isn't the amount of memory, but the
> addresses at which it surfaces. Host memory must not extend
> beyond the 168MiB boundary for that to also be the limit for
> 32-bit PV guests.

Yes, I'd intended "under 168GiB" to more clearly imply physical
addresses; but I agree as written that's unlikely to be picked up by
anyone not already familiar with the concept.

What about something like this:

"32-bit PV guests can only access physical addresses below 168GiB;
this means that the total memory of all 32-bit PV guests cannot exceed
168GiB.  For hosts with more than 168GiB RAM, this limit becomes 128GiB."

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 10/17] SUPPORT.md: Add Debugging, analysis, crash post-portem

[Jan Beulich]

>>> On 23.11.17 at 18:08, <george.dunlap@citrix.com> wrote:
> On 11/23/2017 11:15 AM, Jan Beulich wrote:
>>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>>> +## Debugging, analysis, and crash post-mortem
>>> +
>>> +### Host serial console
>>> +
>>> +    Status, NS16550: Supported
>>> +	Status, EHCI: Supported
>>> +	Status, Cadence UART (ARM): Supported
>>> +	Status, PL011 UART (ARM): Supported
>>> +	Status, Exynos 4210 UART (ARM): Supported
>>> +	Status, OMAP UART (ARM): Supported
>>> +	Status, SCI(F) UART: Supported
>>> +
>>> +XXX Should NS16550 and EHCI be limited to x86?  Unlike the ARM
>>> +entries, they don't depend on x86 being configured
>> 
>> ns16550 ought to be usable everywhere. EHCI is x86-only
>> anyway (presumably first of all because it takes PCI as a prereq)
> 
> But that's just an accident at the moment; I thought there were plans at
> some point for ARM servers to have PCI, weren't there?

Right, at which point EHCI could become usable on ARM, too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 16/17] SUPPORT.md: Add limits RFC

[Jan Beulich]

>>> On 23.11.17 at 18:21, <george.dunlap@citrix.com> wrote:
> On 11/23/2017 11:21 AM, Jan Beulich wrote:
>>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>>> +### 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.
>> 
>> While certainly harder to grok for the reader, I think we need to be
>> precise here: The factor isn't the amount of memory, but the
>> addresses at which it surfaces. Host memory must not extend
>> beyond the 168MiB boundary for that to also be the limit for
>> 32-bit PV guests.
> 
> Yes, I'd intended "under 168GiB" to more clearly imply physical
> addresses; but I agree as written that's unlikely to be picked up by
> anyone not already familiar with the concept.
> 
> What about something like this:
> 
> "32-bit PV guests can only access physical addresses below 168GiB;
> this means that the total memory of all 32-bit PV guests cannot exceed
> 168GiB.  For hosts with more than 168GiB RAM, this limit becomes 128GiB."

Better, but I'd still prefer the last sentence to be something like
"For hosts with memory above the 168GiB boundary, ...". I'm
not going to insist on such an adjustment, though, if you feel
what you have is easier to understand by the intended audience.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 05/17] SUPPORT.md: Toolstack core

[Ian Jackson]

George Dunlap writes ("[PATCH v3 05/17] SUPPORT.md: Toolstack core"):
> For now only include xl-specific features, or interaction with the
> system.  Feature support matrix will be added when features are
> mentioned.
...
> +## Toolstack
> +
> +### xl
> +
> +    Status: Supported
> +
> +### Direct-boot kernel image format
> +
> +    Supported, x86: bzImage
> +    Supported, ARM32: zImage
> +    Supported, ARM64: Image
> +
> +Format which the toolstack accept for direct-boot kernels
            ..                        ^s

...
> +### systemd support for xl
> +
> +    Status: Supported

I think this should probably mention sysvinit if we are going to
mention systemd.  That is also Supported.

With that extra stanza,

Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 05/17] SUPPORT.md: Toolstack core

[George Dunlap]

On 11/24/2017 04:26 PM, Ian Jackson wrote:
> George Dunlap writes ("[PATCH v3 05/17] SUPPORT.md: Toolstack core"):
>> For now only include xl-specific features, or interaction with the
>> system.  Feature support matrix will be added when features are
>> mentioned.
> ...
>> +## Toolstack
>> +
>> +### xl
>> +
>> +    Status: Supported
>> +
>> +### Direct-boot kernel image format
>> +
>> +    Supported, x86: bzImage
>> +    Supported, ARM32: zImage
>> +    Supported, ARM64: Image
>> +
>> +Format which the toolstack accept for direct-boot kernels
>             ..                        ^s
> 
> ...
>> +### systemd support for xl
>> +
>> +    Status: Supported
> 
> I think this should probably mention sysvinit if we are going to
> mention systemd.  That is also Supported.

Ack

> 
> With that extra stanza,
> 
> Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 05/17] SUPPORT.md: Toolstack core

[Roger Pau Monné]

On Wed, Nov 22, 2017 at 07:20:12PM +0000, George Dunlap wrote:
> For now only include xl-specific features, or interaction with the
> system.  Feature support matrix will be added when features are
> mentioned.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> ---
> CC: Ian Jackson <ian.jackson@citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Konrad Wilk <konrad.wilk@oracle.com>
> CC: Tim Deegan <tim@xen.org>
> ---
>  SUPPORT.md | 38 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 5945ab4926..df429cb3c4 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -96,6 +96,44 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM)
>  
>  ARM only has one guest type at the moment
>  
> +## Toolstack
> +
> +### xl
> +
> +    Status: Supported
> +
> +### Direct-boot kernel image format
> +
> +    Supported, x86: bzImage

ELF is missing here.

> +    Supported, ARM32: zImage
> +    Supported, ARM64: Image
> +
> +Format which the toolstack accept for direct-boot kernels
> +
> +### systemd support for xl

BSD-style init is also supported.

The rest LGTM:

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 05/17] SUPPORT.md: Toolstack core

[George Dunlap]

On 11/27/2017 11:43 AM, Roger Pau Monné wrote:
> On Wed, Nov 22, 2017 at 07:20:12PM +0000, George Dunlap wrote:
>> For now only include xl-specific features, or interaction with the
>> system.  Feature support matrix will be added when features are
>> mentioned.
>>
>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>> ---
>> CC: Ian Jackson <ian.jackson@citrix.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
>> CC: Jan Beulich <jbeulich@suse.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Konrad Wilk <konrad.wilk@oracle.com>
>> CC: Tim Deegan <tim@xen.org>
>> ---
>>  SUPPORT.md | 38 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 38 insertions(+)
>>
>> diff --git a/SUPPORT.md b/SUPPORT.md
>> index 5945ab4926..df429cb3c4 100644
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -96,6 +96,44 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM)
>>  
>>  ARM only has one guest type at the moment
>>  
>> +## Toolstack
>> +
>> +### xl
>> +
>> +    Status: Supported
>> +
>> +### Direct-boot kernel image format
>> +
>> +    Supported, x86: bzImage
> 
> ELF is missing here.
> 
>> +    Supported, ARM32: zImage
>> +    Supported, ARM64: Image
>> +
>> +Format which the toolstack accept for direct-boot kernels
>> +
>> +### systemd support for xl
> 
> BSD-style init is also supported.

Is that different than SysV init?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 05/17] SUPPORT.md: Toolstack core

[George Dunlap]

On 11/27/2017 11:43 AM, Roger Pau Monné wrote:
> On Wed, Nov 22, 2017 at 07:20:12PM +0000, George Dunlap wrote:
>> For now only include xl-specific features, or interaction with the
>> system.  Feature support matrix will be added when features are
>> mentioned.
>>
>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>> ---
>> CC: Ian Jackson <ian.jackson@citrix.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
>> CC: Jan Beulich <jbeulich@suse.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Konrad Wilk <konrad.wilk@oracle.com>
>> CC: Tim Deegan <tim@xen.org>
>> ---
>>  SUPPORT.md | 38 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 38 insertions(+)
>>
>> diff --git a/SUPPORT.md b/SUPPORT.md
>> index 5945ab4926..df429cb3c4 100644
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -96,6 +96,44 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM)
>>  
>>  ARM only has one guest type at the moment
>>  
>> +## Toolstack
>> +
>> +### xl
>> +
>> +    Status: Supported
>> +
>> +### Direct-boot kernel image format
>> +
>> +    Supported, x86: bzImage
> 
> ELF is missing here.

Are you suggesting adding ELF just after bzImage?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 10/17] SUPPORT.md: Add Debugging, analysis, crash post-portem

[George Dunlap]

On 11/24/2017 08:04 AM, Jan Beulich wrote:
>>>> On 23.11.17 at 18:08, <george.dunlap@citrix.com> wrote:
>> On 11/23/2017 11:15 AM, Jan Beulich wrote:
>>>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>>>> +## Debugging, analysis, and crash post-mortem
>>>> +
>>>> +### Host serial console
>>>> +
>>>> +    Status, NS16550: Supported
>>>> +	Status, EHCI: Supported
>>>> +	Status, Cadence UART (ARM): Supported
>>>> +	Status, PL011 UART (ARM): Supported
>>>> +	Status, Exynos 4210 UART (ARM): Supported
>>>> +	Status, OMAP UART (ARM): Supported
>>>> +	Status, SCI(F) UART: Supported
>>>> +
>>>> +XXX Should NS16550 and EHCI be limited to x86?  Unlike the ARM
>>>> +entries, they don't depend on x86 being configured
>>>
>>> ns16550 ought to be usable everywhere. EHCI is x86-only
>>> anyway (presumably first of all because it takes PCI as a prereq)
>>
>> But that's just an accident at the moment; I thought there were plans at
>> some point for ARM servers to have PCI, weren't there?
> 
> Right, at which point EHCI could become usable on ARM, too.

OK -- so I think for now I'll leave it unspecified.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 16/17] SUPPORT.md: Add limits RFC

[George Dunlap]

On 11/24/2017 08:14 AM, Jan Beulich wrote:
>>>> On 23.11.17 at 18:21, <george.dunlap@citrix.com> wrote:
>> On 11/23/2017 11:21 AM, Jan Beulich wrote:
>>>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>>>> +### 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.
>>>
>>> While certainly harder to grok for the reader, I think we need to be
>>> precise here: The factor isn't the amount of memory, but the
>>> addresses at which it surfaces. Host memory must not extend
>>> beyond the 168MiB boundary for that to also be the limit for
>>> 32-bit PV guests.
>>
>> Yes, I'd intended "under 168GiB" to more clearly imply physical
>> addresses; but I agree as written that's unlikely to be picked up by
>> anyone not already familiar with the concept.
>>
>> What about something like this:
>>
>> "32-bit PV guests can only access physical addresses below 168GiB;
>> this means that the total memory of all 32-bit PV guests cannot exceed
>> 168GiB.  For hosts with more than 168GiB RAM, this limit becomes 128GiB."
> 
> Better, but I'd still prefer the last sentence to be something like
> "For hosts with memory above the 168GiB boundary, ...". I'm
> not going to insist on such an adjustment, though, if you feel
> what you have is easier to understand by the intended audience.

This is an area where the underlying complexity is really
(unfortunately) exposed to the user; I think hinting that there's
something complicated is OK, even if the user isn't necessarily expected
to understand it 100%.

I've changed it to the following (minus word wrapping):

---
32-bit PV guests can only access physical addresses below 168GiB;
this means that the total memory of all 32-bit PV guests cannot exceed
168GiB.
For hosts with memory above the 168GiB address boundary,
this limit becomes 128GiB.
---

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 05/17] SUPPORT.md: Toolstack core

[Roger Pau Monné]

On Mon, Nov 27, 2017 at 02:15:50PM +0000, George Dunlap wrote:
> On 11/27/2017 11:43 AM, Roger Pau Monné wrote:
> > On Wed, Nov 22, 2017 at 07:20:12PM +0000, George Dunlap wrote:
> >> For now only include xl-specific features, or interaction with the
> >> system.  Feature support matrix will be added when features are
> >> mentioned.
> >>
> >> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> >> ---
> >> CC: Ian Jackson <ian.jackson@citrix.com>
> >> CC: Wei Liu <wei.liu2@citrix.com>
> >> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> >> CC: Jan Beulich <jbeulich@suse.com>
> >> CC: Stefano Stabellini <sstabellini@kernel.org>
> >> CC: Konrad Wilk <konrad.wilk@oracle.com>
> >> CC: Tim Deegan <tim@xen.org>
> >> ---
> >>  SUPPORT.md | 38 ++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 38 insertions(+)
> >>
> >> diff --git a/SUPPORT.md b/SUPPORT.md
> >> index 5945ab4926..df429cb3c4 100644
> >> --- a/SUPPORT.md
> >> +++ b/SUPPORT.md
> >> @@ -96,6 +96,44 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM)
> >>  
> >>  ARM only has one guest type at the moment
> >>  
> >> +## Toolstack
> >> +
> >> +### xl
> >> +
> >> +    Status: Supported
> >> +
> >> +### Direct-boot kernel image format
> >> +
> >> +    Supported, x86: bzImage
> > 
> > ELF is missing here.
> 
> Are you suggesting adding ELF just after bzImage?

Yes, that's right.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 05/17] SUPPORT.md: Toolstack core

[Roger Pau Monné]

On Mon, Nov 27, 2017 at 02:12:40PM +0000, George Dunlap wrote:
> On 11/27/2017 11:43 AM, Roger Pau Monné wrote:
> > On Wed, Nov 22, 2017 at 07:20:12PM +0000, George Dunlap wrote:
> >> For now only include xl-specific features, or interaction with the
> >> system.  Feature support matrix will be added when features are
> >> mentioned.
> >>
> >> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> >> ---
> >> CC: Ian Jackson <ian.jackson@citrix.com>
> >> CC: Wei Liu <wei.liu2@citrix.com>
> >> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> >> CC: Jan Beulich <jbeulich@suse.com>
> >> CC: Stefano Stabellini <sstabellini@kernel.org>
> >> CC: Konrad Wilk <konrad.wilk@oracle.com>
> >> CC: Tim Deegan <tim@xen.org>
> >> ---
> >>  SUPPORT.md | 38 ++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 38 insertions(+)
> >>
> >> diff --git a/SUPPORT.md b/SUPPORT.md
> >> index 5945ab4926..df429cb3c4 100644
> >> --- a/SUPPORT.md
> >> +++ b/SUPPORT.md
> >> @@ -96,6 +96,44 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM)
> >>  
> >>  ARM only has one guest type at the moment
> >>  
> >> +## Toolstack
> >> +
> >> +### xl
> >> +
> >> +    Status: Supported
> >> +
> >> +### Direct-boot kernel image format
> >> +
> >> +    Supported, x86: bzImage
> > 
> > ELF is missing here.
> > 
> >> +    Supported, ARM32: zImage
> >> +    Supported, ARM64: Image
> >> +
> >> +Format which the toolstack accept for direct-boot kernels
> >> +
> >> +### systemd support for xl
> > 
> > BSD-style init is also supported.
> 
> Is that different than SysV init?

It seems so but I'm no expert. The FreeBSD handbook states [0]:

"Many Linux(c) distributions use the SysV init system, whereas FreeBSD
uses the traditional BSD-style init(8). Under the BSD-style init(8),
there are no run-levels and /etc/inittab does not exist. Instead,
startup is controlled by rc(8) scripts."

So if systemd and SysV are listed, BSD-style init should also be
listed.

Thanks, Roger.

[0] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/linux-users/startup.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 05/17] SUPPORT.md: Toolstack core

[George Dunlap]

On 11/27/2017 02:39 PM, Roger Pau Monné wrote:
> On Mon, Nov 27, 2017 at 02:12:40PM +0000, George Dunlap wrote:
>> On 11/27/2017 11:43 AM, Roger Pau Monné wrote:
>>> On Wed, Nov 22, 2017 at 07:20:12PM +0000, George Dunlap wrote:
>>>> For now only include xl-specific features, or interaction with the
>>>> system.  Feature support matrix will be added when features are
>>>> mentioned.
>>>>
>>>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>>>> ---
>>>> CC: Ian Jackson <ian.jackson@citrix.com>
>>>> CC: Wei Liu <wei.liu2@citrix.com>
>>>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> CC: Jan Beulich <jbeulich@suse.com>
>>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>> CC: Konrad Wilk <konrad.wilk@oracle.com>
>>>> CC: Tim Deegan <tim@xen.org>
>>>> ---
>>>>  SUPPORT.md | 38 ++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 38 insertions(+)
>>>>
>>>> diff --git a/SUPPORT.md b/SUPPORT.md
>>>> index 5945ab4926..df429cb3c4 100644
>>>> --- a/SUPPORT.md
>>>> +++ b/SUPPORT.md
>>>> @@ -96,6 +96,44 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM)
>>>>  
>>>>  ARM only has one guest type at the moment
>>>>  
>>>> +## Toolstack
>>>> +
>>>> +### xl
>>>> +
>>>> +    Status: Supported
>>>> +
>>>> +### Direct-boot kernel image format
>>>> +
>>>> +    Supported, x86: bzImage
>>>
>>> ELF is missing here.
>>>
>>>> +    Supported, ARM32: zImage
>>>> +    Supported, ARM64: Image
>>>> +
>>>> +Format which the toolstack accept for direct-boot kernels
>>>> +
>>>> +### systemd support for xl
>>>
>>> BSD-style init is also supported.
>>
>> Is that different than SysV init?
> 
> It seems so but I'm no expert. The FreeBSD handbook states [0]:
> 
> "Many Linux(c) distributions use the SysV init system, whereas FreeBSD
> uses the traditional BSD-style init(8). Under the BSD-style init(8),
> there are no run-levels and /etc/inittab does not exist. Instead,
> startup is controlled by rc(8) scripts."
> 
> So if systemd and SysV are listed, BSD-style init should also be
> listed.

Got it, thanks.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 14/17] SUPPORT.md: Add statement on PCI passthrough

[George Dunlap]

On 11/23/2017 11:17 AM, Jan Beulich wrote:
>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> 
> With the XXX suitably addressed
> Acked-by: Jan Beulich <jbeulich@suse.com>

Would you give an Ack for the XXX line simply removed to begin with?  Or
would you rather wait for this to go in until we have an in-tree
reference to give people?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 05/17] SUPPORT.md: Toolstack core

[George Dunlap]

On 11/27/2017 02:39 PM, Roger Pau Monné wrote:
> On Mon, Nov 27, 2017 at 02:12:40PM +0000, George Dunlap wrote:
>> On 11/27/2017 11:43 AM, Roger Pau Monné wrote:
>>> On Wed, Nov 22, 2017 at 07:20:12PM +0000, George Dunlap wrote:
>>>> For now only include xl-specific features, or interaction with the
>>>> system.  Feature support matrix will be added when features are
>>>> mentioned.
>>>>
>>>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>>>> ---
>>>> CC: Ian Jackson <ian.jackson@citrix.com>
>>>> CC: Wei Liu <wei.liu2@citrix.com>
>>>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> CC: Jan Beulich <jbeulich@suse.com>
>>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>> CC: Konrad Wilk <konrad.wilk@oracle.com>
>>>> CC: Tim Deegan <tim@xen.org>
>>>> ---
>>>>  SUPPORT.md | 38 ++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 38 insertions(+)
>>>>
>>>> diff --git a/SUPPORT.md b/SUPPORT.md
>>>> index 5945ab4926..df429cb3c4 100644
>>>> --- a/SUPPORT.md
>>>> +++ b/SUPPORT.md
>>>> @@ -96,6 +96,44 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM)
>>>>  
>>>>  ARM only has one guest type at the moment
>>>>  
>>>> +## Toolstack
>>>> +
>>>> +### xl
>>>> +
>>>> +    Status: Supported
>>>> +
>>>> +### Direct-boot kernel image format
>>>> +
>>>> +    Supported, x86: bzImage
>>>
>>> ELF is missing here.
>>>
>>>> +    Supported, ARM32: zImage
>>>> +    Supported, ARM64: Image
>>>> +
>>>> +Format which the toolstack accept for direct-boot kernels
>>>> +
>>>> +### systemd support for xl
>>>
>>> BSD-style init is also supported.
>>
>> Is that different than SysV init?
> 
> It seems so but I'm no expert. The FreeBSD handbook states [0]:
> 
> "Many Linux(c) distributions use the SysV init system, whereas FreeBSD
> uses the traditional BSD-style init(8). Under the BSD-style init(8),
> there are no run-levels and /etc/inittab does not exist. Instead,
> startup is controlled by rc(8) scripts."
> 
> So if systemd and SysV are listed, BSD-style init should also be
> listed.

OK, I've modified these to look like this:

---
### Dom0 init support for xl

    Status, SysV: Supported
    Status, systemd: Supported
    Status, BSD-style: Supported
---

Does that sound good?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 05/17] SUPPORT.md: Toolstack core

[Roger Pau Monné]

On Mon, Nov 27, 2017 at 02:58:38PM +0000, George Dunlap wrote:
> On 11/27/2017 02:39 PM, Roger Pau Monné wrote:
> > On Mon, Nov 27, 2017 at 02:12:40PM +0000, George Dunlap wrote:
> >> On 11/27/2017 11:43 AM, Roger Pau Monné wrote:
> >>> On Wed, Nov 22, 2017 at 07:20:12PM +0000, George Dunlap wrote:
> >>>> For now only include xl-specific features, or interaction with the
> >>>> system.  Feature support matrix will be added when features are
> >>>> mentioned.
> >>>>
> >>>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> >>>> ---
> >>>> CC: Ian Jackson <ian.jackson@citrix.com>
> >>>> CC: Wei Liu <wei.liu2@citrix.com>
> >>>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> >>>> CC: Jan Beulich <jbeulich@suse.com>
> >>>> CC: Stefano Stabellini <sstabellini@kernel.org>
> >>>> CC: Konrad Wilk <konrad.wilk@oracle.com>
> >>>> CC: Tim Deegan <tim@xen.org>
> >>>> ---
> >>>>  SUPPORT.md | 38 ++++++++++++++++++++++++++++++++++++++
> >>>>  1 file changed, 38 insertions(+)
> >>>>
> >>>> diff --git a/SUPPORT.md b/SUPPORT.md
> >>>> index 5945ab4926..df429cb3c4 100644
> >>>> --- a/SUPPORT.md
> >>>> +++ b/SUPPORT.md
> >>>> @@ -96,6 +96,44 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM)
> >>>>  
> >>>>  ARM only has one guest type at the moment
> >>>>  
> >>>> +## Toolstack
> >>>> +
> >>>> +### xl
> >>>> +
> >>>> +    Status: Supported
> >>>> +
> >>>> +### Direct-boot kernel image format
> >>>> +
> >>>> +    Supported, x86: bzImage
> >>>
> >>> ELF is missing here.
> >>>
> >>>> +    Supported, ARM32: zImage
> >>>> +    Supported, ARM64: Image
> >>>> +
> >>>> +Format which the toolstack accept for direct-boot kernels
> >>>> +
> >>>> +### systemd support for xl
> >>>
> >>> BSD-style init is also supported.
> >>
> >> Is that different than SysV init?
> > 
> > It seems so but I'm no expert. The FreeBSD handbook states [0]:
> > 
> > "Many Linux(c) distributions use the SysV init system, whereas FreeBSD
> > uses the traditional BSD-style init(8). Under the BSD-style init(8),
> > there are no run-levels and /etc/inittab does not exist. Instead,
> > startup is controlled by rc(8) scripts."
> > 
> > So if systemd and SysV are listed, BSD-style init should also be
> > listed.
> 
> OK, I've modified these to look like this:
> 
> ---
> ### Dom0 init support for xl
> 
>     Status, SysV: Supported
>     Status, systemd: Supported
>     Status, BSD-style: Supported
> ---
> 
> Does that sound good?

Yes, that LGTM.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 14/17] SUPPORT.md: Add statement on PCI passthrough

[Jan Beulich]

>>> On 27.11.17 at 15:48, <george.dunlap@citrix.com> wrote:
> On 11/23/2017 11:17 AM, Jan Beulich wrote:
>>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>> 
>> With the XXX suitably addressed
>> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> Would you give an Ack for the XXX line simply removed to begin with?  Or
> would you rather wait for this to go in until we have an in-tree
> reference to give people?

I think simply removing the line is better than waiting for the file to
appear; the ack applies either way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 14/17] SUPPORT.md: Add statement on PCI passthrough

[George Dunlap]

On 11/27/2017 03:04 PM, Jan Beulich wrote:
>>>> On 27.11.17 at 15:48, <george.dunlap@citrix.com> wrote:
>> On 11/23/2017 11:17 AM, Jan Beulich wrote:
>>>>>> On 22.11.17 at 20:20, <george.dunlap@citrix.com> wrote:
>>>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>>>
>>> With the XXX suitably addressed
>>> Acked-by: Jan Beulich <jbeulich@suse.com>
>>
>> Would you give an Ack for the XXX line simply removed to begin with?  Or
>> would you rather wait for this to go in until we have an in-tree
>> reference to give people?
> 
> I think simply removing the line is better than waiting for the file to
> appear; the ack applies either way.

Great, it was the last phrase I was looking for. :-) (i.e., whether
"remove it" would be a "suitable" way of addressing it).

Thanks,
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 08/17] SUPPORT.md: Add x86-specific virtual hardware

[Anthony PERARD]

On Wed, Nov 22, 2017 at 07:20:15PM +0000, George Dunlap wrote:
> x86-specific virtual hardware provided by the hypervisor, toolstack,
> or QEMU.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> ---
> Changes since v2:
> - Updated Nested PV / HVM sections
> - Removed AVX section
> - EFI -> OVMF
> 
> Changes since v1:
> - Added emulated QEMU support, to replace docs/misc/qemu-xen-security.
> 
> Need to figure out what to do with the "backing storage image format"
> section of that document.
> 
> CC: Ian Jackson <ian.jackson@citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Konrad Wilk <konrad.wilk@oracle.com>
> CC: Tim Deegan <tim@xen.org>
> CC: Roger Pau Monne <roger.pau@citrix.com>
> CC: Anthony Perard <anthony.perard@citrix.com>
> CC: Paul Durrant <paul.durrant@citrix.com>
> ---
>  SUPPORT.md | 105 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 105 insertions(+)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 96c381fb55..98ed18098a 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -373,6 +373,111 @@ but has no xl support.
>  
>      Status: Supported
>  
> +## Virtual Hardware, Hypervisor
> +
> +### x86/Nested PV
> +
> +    Status, x86 Xen HVM: Tech Preview
> +
> +This means running a Xen hypervisor inside an HVM domain on a Xen system,
> +with support for PV L2 guests only
> +(i.e., hardware virtualization extensions not provided
> +to the guest).
> +
> +This works, but has performance limitations
> +because the L1 dom0 can only access emulated L1 devices.
> +
> +Xen may also run inside other hypervisors (KVM, Hyper-V, VMWare),
> +but nobody has reported on performance.
> +
> +### x86/Nested HVM
> +
> +    Status, x86 HVM: Experimental
> +
> +This means providing hardware virtulatization support to guest VMs
> +allowing, for instance, a nested Xen to support both PV and HVM guests.
> +It also implies support for other hypervisors,
> +such as KVM, Hyper-V, Bromium, and so on as guests.
> +
> +### vPMU
> +
> +    Status, x86: Supported, Not security supported
> +
> +Virtual Performance Management Unit for HVM guests
> +
> +Disabled by default (enable with hypervisor command line option).
> +This feature is not security supported: see http://xenbits.xen.org/xsa/advisory-163.html
> +
> +## Virtual Hardware, QEMU
> +
> +These are devices available in HVM mode using a qemu devicemodel (the default).
> +Note that other devices are available but not security supported.
> +
> +### x86/Emulated platform devices (QEMU):
> +
> +    Status, piix3: Supported
> +
> +### x86/Emulated network (QEMU):
> +
> +    Status, e1000: Supported
> +    Status, rtl8193: Supported
> +    Status, virtio-net: Supported
> +
> +### x86/Emulated storage (QEMU):
> +
> +    Status, piix3 ide: Supported
> +    Status, ahci: Supported
> +
> +### x86/Emulated graphics (QEMU):
> +
> +    Status, cirrus-vga: Supported
> +    Status, stgvga: Supported
> +
> +### x86/Emulated audio (QEMU):
> +
> +    Status, sb16: Supported
> +    Status, es1370: Supported
> +    Status, ac97: Supported
> +
> +### x86/Emulated input (QEMU):
> +
> +    Status, usbmouse: Supported
> +    Status, usbtablet: Supported
> +    Status, ps/2 keyboard: Supported
> +    Status, ps/2 mouse: Supported
> +
> +### x86/Emulated serial card (QEMU):
> +
> +    Status, UART 16550A: Supported
> +
> +### x86/Host USB passthrough (QEMU):
> +
> +    Status: Supported, not security supported
> +
> +## Virtual Firmware
> +
> +### x86/HVM iPXE
> +
> +    Status: Supported, with caveats
> +
> +Booting a guest via PXE.
> +PXE inherently places full trust of the guest in the network,
> +and so should only be used
> +when the guest network is under the same administrative control
> +as the guest itself.
> +
> +### x86/HVM BIOS
> +
> +    Status: Supported
> +
> +Booting a guest via guest BIOS firmware

Should we mention that the supported BIOS are either SeaBIOS or ROMBIOS
like it is done bellow for UEFI?

> +
> +### x86/HVM OVMF
> +
> +    Status: Supported
> +
> +OVMF firmware implements the UEFI boot protocol.

Otherwise, the patch looks good to me.
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 08/17] SUPPORT.md: Add x86-specific virtual hardware

[George Dunlap]

On 11/27/2017 03:12 PM, Anthony PERARD wrote:
> On Wed, Nov 22, 2017 at 07:20:15PM +0000, George Dunlap wrote:
>> x86-specific virtual hardware provided by the hypervisor, toolstack,
>> or QEMU.
>>
>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>> ---
>> Changes since v2:
>> - Updated Nested PV / HVM sections
>> - Removed AVX section
>> - EFI -> OVMF
>>
>> Changes since v1:
>> - Added emulated QEMU support, to replace docs/misc/qemu-xen-security.
>>
>> Need to figure out what to do with the "backing storage image format"
>> section of that document.
>>
>> CC: Ian Jackson <ian.jackson@citrix.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
>> CC: Jan Beulich <jbeulich@suse.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Konrad Wilk <konrad.wilk@oracle.com>
>> CC: Tim Deegan <tim@xen.org>
>> CC: Roger Pau Monne <roger.pau@citrix.com>
>> CC: Anthony Perard <anthony.perard@citrix.com>
>> CC: Paul Durrant <paul.durrant@citrix.com>
>> ---
>>  SUPPORT.md | 105 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 105 insertions(+)
>>
>> diff --git a/SUPPORT.md b/SUPPORT.md
>> index 96c381fb55..98ed18098a 100644
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -373,6 +373,111 @@ but has no xl support.
>>  
>>      Status: Supported
>>  
>> +## Virtual Hardware, Hypervisor
>> +
>> +### x86/Nested PV
>> +
>> +    Status, x86 Xen HVM: Tech Preview
>> +
>> +This means running a Xen hypervisor inside an HVM domain on a Xen system,
>> +with support for PV L2 guests only
>> +(i.e., hardware virtualization extensions not provided
>> +to the guest).
>> +
>> +This works, but has performance limitations
>> +because the L1 dom0 can only access emulated L1 devices.
>> +
>> +Xen may also run inside other hypervisors (KVM, Hyper-V, VMWare),
>> +but nobody has reported on performance.
>> +
>> +### x86/Nested HVM
>> +
>> +    Status, x86 HVM: Experimental
>> +
>> +This means providing hardware virtulatization support to guest VMs
>> +allowing, for instance, a nested Xen to support both PV and HVM guests.
>> +It also implies support for other hypervisors,
>> +such as KVM, Hyper-V, Bromium, and so on as guests.
>> +
>> +### vPMU
>> +
>> +    Status, x86: Supported, Not security supported
>> +
>> +Virtual Performance Management Unit for HVM guests
>> +
>> +Disabled by default (enable with hypervisor command line option).
>> +This feature is not security supported: see http://xenbits.xen.org/xsa/advisory-163.html
>> +
>> +## Virtual Hardware, QEMU
>> +
>> +These are devices available in HVM mode using a qemu devicemodel (the default).
>> +Note that other devices are available but not security supported.
>> +
>> +### x86/Emulated platform devices (QEMU):
>> +
>> +    Status, piix3: Supported
>> +
>> +### x86/Emulated network (QEMU):
>> +
>> +    Status, e1000: Supported
>> +    Status, rtl8193: Supported
>> +    Status, virtio-net: Supported
>> +
>> +### x86/Emulated storage (QEMU):
>> +
>> +    Status, piix3 ide: Supported
>> +    Status, ahci: Supported
>> +
>> +### x86/Emulated graphics (QEMU):
>> +
>> +    Status, cirrus-vga: Supported
>> +    Status, stgvga: Supported
>> +
>> +### x86/Emulated audio (QEMU):
>> +
>> +    Status, sb16: Supported
>> +    Status, es1370: Supported
>> +    Status, ac97: Supported
>> +
>> +### x86/Emulated input (QEMU):
>> +
>> +    Status, usbmouse: Supported
>> +    Status, usbtablet: Supported
>> +    Status, ps/2 keyboard: Supported
>> +    Status, ps/2 mouse: Supported
>> +
>> +### x86/Emulated serial card (QEMU):
>> +
>> +    Status, UART 16550A: Supported
>> +
>> +### x86/Host USB passthrough (QEMU):
>> +
>> +    Status: Supported, not security supported
>> +
>> +## Virtual Firmware
>> +
>> +### x86/HVM iPXE
>> +
>> +    Status: Supported, with caveats
>> +
>> +Booting a guest via PXE.
>> +PXE inherently places full trust of the guest in the network,
>> +and so should only be used
>> +when the guest network is under the same administrative control
>> +as the guest itself.
>> +
>> +### x86/HVM BIOS
>> +
>> +    Status: Supported
>> +
>> +Booting a guest via guest BIOS firmware
> 
> Should we mention that the supported BIOS are either SeaBIOS or ROMBIOS
> like it is done bellow for UEFI?

What about something like this:

---
### x86/HVM BIOS

    Status, SeaBIOS (qemu-xen): Supported
    Status, ROMBIOS (qemu-xen-traditional): Supported

Booting a guest via guest BIOS firmware
---

Hmm, but that rather implies that we should change OVMF to the following:

---
### x86/HVM OVMF

    Status, qemu-xen: Supported

OVMF firmware implements the UEFI boot protocol.
---


What do you think?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 08/17] SUPPORT.md: Add x86-specific virtual hardware

[Anthony PERARD]

On Mon, Nov 27, 2017 at 04:30:36PM +0000, George Dunlap wrote:
> On 11/27/2017 03:12 PM, Anthony PERARD wrote:
> > On Wed, Nov 22, 2017 at 07:20:15PM +0000, George Dunlap wrote:
> >> x86-specific virtual hardware provided by the hypervisor, toolstack,
> >> or QEMU.
> >>
> >> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> >> ---
> >> Changes since v2:
> >> - Updated Nested PV / HVM sections
> >> - Removed AVX section
> >> - EFI -> OVMF
> >>
> >> Changes since v1:
> >> - Added emulated QEMU support, to replace docs/misc/qemu-xen-security.
> >>
> >> Need to figure out what to do with the "backing storage image format"
> >> section of that document.
> >>
> >> CC: Ian Jackson <ian.jackson@citrix.com>
> >> CC: Wei Liu <wei.liu2@citrix.com>
> >> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> >> CC: Jan Beulich <jbeulich@suse.com>
> >> CC: Stefano Stabellini <sstabellini@kernel.org>
> >> CC: Konrad Wilk <konrad.wilk@oracle.com>
> >> CC: Tim Deegan <tim@xen.org>
> >> CC: Roger Pau Monne <roger.pau@citrix.com>
> >> CC: Anthony Perard <anthony.perard@citrix.com>
> >> CC: Paul Durrant <paul.durrant@citrix.com>
> >> ---
> >>  SUPPORT.md | 105 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 105 insertions(+)
> >>
> >> diff --git a/SUPPORT.md b/SUPPORT.md
> >> index 96c381fb55..98ed18098a 100644
> >> --- a/SUPPORT.md
> >> +++ b/SUPPORT.md
> >> @@ -373,6 +373,111 @@ but has no xl support.
> >>  
> >>      Status: Supported
> >>  
> >> +## Virtual Hardware, Hypervisor
> >> +
> >> +### x86/Nested PV
> >> +
> >> +    Status, x86 Xen HVM: Tech Preview
> >> +
> >> +This means running a Xen hypervisor inside an HVM domain on a Xen system,
> >> +with support for PV L2 guests only
> >> +(i.e., hardware virtualization extensions not provided
> >> +to the guest).
> >> +
> >> +This works, but has performance limitations
> >> +because the L1 dom0 can only access emulated L1 devices.
> >> +
> >> +Xen may also run inside other hypervisors (KVM, Hyper-V, VMWare),
> >> +but nobody has reported on performance.
> >> +
> >> +### x86/Nested HVM
> >> +
> >> +    Status, x86 HVM: Experimental
> >> +
> >> +This means providing hardware virtulatization support to guest VMs
> >> +allowing, for instance, a nested Xen to support both PV and HVM guests.
> >> +It also implies support for other hypervisors,
> >> +such as KVM, Hyper-V, Bromium, and so on as guests.
> >> +
> >> +### vPMU
> >> +
> >> +    Status, x86: Supported, Not security supported
> >> +
> >> +Virtual Performance Management Unit for HVM guests
> >> +
> >> +Disabled by default (enable with hypervisor command line option).
> >> +This feature is not security supported: see http://xenbits.xen.org/xsa/advisory-163.html
> >> +
> >> +## Virtual Hardware, QEMU
> >> +
> >> +These are devices available in HVM mode using a qemu devicemodel (the default).
> >> +Note that other devices are available but not security supported.
> >> +
> >> +### x86/Emulated platform devices (QEMU):
> >> +
> >> +    Status, piix3: Supported
> >> +
> >> +### x86/Emulated network (QEMU):
> >> +
> >> +    Status, e1000: Supported
> >> +    Status, rtl8193: Supported
> >> +    Status, virtio-net: Supported
> >> +
> >> +### x86/Emulated storage (QEMU):
> >> +
> >> +    Status, piix3 ide: Supported
> >> +    Status, ahci: Supported
> >> +
> >> +### x86/Emulated graphics (QEMU):
> >> +
> >> +    Status, cirrus-vga: Supported
> >> +    Status, stgvga: Supported
> >> +
> >> +### x86/Emulated audio (QEMU):
> >> +
> >> +    Status, sb16: Supported
> >> +    Status, es1370: Supported
> >> +    Status, ac97: Supported
> >> +
> >> +### x86/Emulated input (QEMU):
> >> +
> >> +    Status, usbmouse: Supported
> >> +    Status, usbtablet: Supported
> >> +    Status, ps/2 keyboard: Supported
> >> +    Status, ps/2 mouse: Supported
> >> +
> >> +### x86/Emulated serial card (QEMU):
> >> +
> >> +    Status, UART 16550A: Supported
> >> +
> >> +### x86/Host USB passthrough (QEMU):
> >> +
> >> +    Status: Supported, not security supported
> >> +
> >> +## Virtual Firmware
> >> +
> >> +### x86/HVM iPXE
> >> +
> >> +    Status: Supported, with caveats
> >> +
> >> +Booting a guest via PXE.
> >> +PXE inherently places full trust of the guest in the network,
> >> +and so should only be used
> >> +when the guest network is under the same administrative control
> >> +as the guest itself.
> >> +
> >> +### x86/HVM BIOS
> >> +
> >> +    Status: Supported
> >> +
> >> +Booting a guest via guest BIOS firmware
> > 
> > Should we mention that the supported BIOS are either SeaBIOS or ROMBIOS
> > like it is done bellow for UEFI?
> 
> What about something like this:
> 
> ---
> ### x86/HVM BIOS
> 
>     Status, SeaBIOS (qemu-xen): Supported
>     Status, ROMBIOS (qemu-xen-traditional): Supported
> 
> Booting a guest via guest BIOS firmware
> ---
> 
> Hmm, but that rather implies that we should change OVMF to the following:
> 
> ---
> ### x86/HVM OVMF
> 
>     Status, qemu-xen: Supported
> 
> OVMF firmware implements the UEFI boot protocol.
> ---
> 
> 
> What do you think?

Sounds good to me.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel