[Xen-devel] [PATCH RFC] Add SUPPORT.md

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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.

Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxx>
Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>

[1] http://rhodesmill.org/brandon/2012/one-sentence-per-line/
---

Definitely meant to be a draft; if you disagree with the status of one
of these features, now is the time to suggest something else.

I've made a number of stylistic decisions that people may have opinions on:

* When dealing with multiple implementations of the same feature (for
  instance, x86/PV x86/HVM and ARM guest types, or Linux / FreeBSD /
  QEMU backends), I decided in general to combine the feature itself
  into a single stanza, and break the 'Status' line up by specifying
  the implementation.

  For example, if a feature is supported on x86 but tech preview on
  ARM, there would be two status lines, thus:

    Status, x86: Supported
    Status, ARM: Tech preview

  If a feature is not implemented for a specific implementation, it
  will simply not be listed:

    Status, x86: Supported

* I've added common 'Support variations' to the bottom of the document

Thinking on support status of specific features:

gdbsx security support: Someone may want to debug an untrusted guest,
so I think we should say 'yes' here.

xentrace: Users may want to trace guests in production environments,
so I think we should say 'yes'.

gcov: No good reason to run a gcov hypervisor in a production
environment.  May be ways for a rogue guest to DoS.

memory paging: Changed to experimental -- are we testing it at all?

alternative p2m: No security support until better testing in place

ARINC653 scheduler: Not sure we have the expertise to properly fix
bugs.  Can switch to 'supported' if we get commitment from
maintainers.

vMCE: Is MCE an x86-only thing, or could this conceivably by extended
to ARM?

PVHv2: Not sure why we'd downgrade guest support to 'experimental'.

ARM/Virtual RAM: Not sure what the note 'Limited by supported host
memory' was supposed to mean

CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
CC: Wei Liu <wei.liu2@xxxxxxxxxx>
CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
CC: Jan Beulich <jbeulich@xxxxxxxx>
CC: Tim Deegan <tim@xxxxxxx>
CC: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
CC: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
CC: Roger Pau Monne <roger.pau@xxxxxxxxxx>
CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
CC: Anthony Perard <anthony.perard@xxxxxxxxxx>
CC: Paul Durrant <paul.durrant@xxxxxxxxxx>
CC: Konrad Wilk <konrad.wilk@xxxxxxxxxx>
---
 SUPPORT.md | 770 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 770 insertions(+)
 create mode 100644 SUPPORT.md

diff --git a/SUPPORT.md b/SUPPORT.md
new file mode 100644
index 0000000000..283cbeb725
--- /dev/null
+++ b/SUPPORT.md
@@ -0,0 +1,770 @@
+# 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
+
+## Host Architecture
+
+### x86-64
+
+    Status: Supported
+
+### ARM v7 + Virtualization Extensions
+
+    Status: Supported
+
+### ARM v8
+
+    Status: Supported
+
+## Guest Type
+
+### x86/PV
+
+    Status: Supported
+
+Traditional Xen Project PV guest
+
+### x86/HVM
+
+    Status: Supported
+
+Fully virtualised guest using hardware virtualisation extensions
+
+Requires hardware virtualisation support
+
+### x86/PV-on-HVM
+
+    Status: Supported
+
+Fully virtualised guest using PV extensions/drivers for improved performance
+
+Requires hardware virtualisation support
+
+### x86/PVH guest
+
+    Status: Preview
+
+PVHv2 guest support
+
+Requires hardware virtualisation support
+
+### x86/PVH dom0
+
+    Status: Experimental
+
+PVHv2 domain 0 support
+
+### ARM guest
+
+    Status: Supported
+
+ARM only has one guest type at the moment
+
+## 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: 16TiB
+    Limit, ARM32: 16GiB
+    Limit, ARM64: 5TiB
+
+[XXX: Andy to suggest what this should say for x86]
+
+## Limits/Guest
+
+### Virtual CPUs
+
+    Limit, x86 PV: 512
+    Limit, x86 HVM: 128
+    Limit, ARM32: 8
+    Limit, ARM64: 128
+
+### x86/PV/Virtual RAM
+
+    Limit, x86 PV: >1TB
+    Limit, x86 HVM: 1TB
+    Limit, ARM32: 16GiB
+    Limit, ARM64: 1TB
+
+### x86 PV/Event Channels
+
+    Limit: 131072
+
+## Toolstack
+
+### xl
+
+    Status: Supported
+
+### Direct-boot kernel image format
+
+    Supported, x86: bzImage
+    Supported, ARM32: zImage
+    Supported, ARM64: Image [XXX - Not sure if this is correct]
+
+Format which the toolstack accept for direct-boot kernels
+
+### Qemu based disk backend (qdisk) for xl
+
+    Status: Supported
+
+### Open vSwitch integration for xl
+
+    Status: Supported
+
+### systemd support for xl
+
+    Status: Supported
+
+### JSON support for xl
+
+    Status: Preview
+
+### AHCI support for xl
+
+    Status, x86: Supported
+
+### ACPI guest
+
+    Status, ARM: Preview
+
+### PVUSB support for xl
+
+    Status: Supported
+
+### HVM USB passthrough for xl
+
+    Status, x86: Supported
+
+### QEMU backend hotplugging for xl
+
+    Status: Supported
+
+### Soft-reset for xl
+
+    Status: Supported
+
+### Virtual cpu hotplug
+
+    Status, ARM: Supported
+
+## Toolstack/3rd party
+
+### libvirt driver for xl
+
+    Status: Supported, Security support external
+
+Security support for libvirt is provided by the libvirt project.
+See https://libvirt.org/securityprocess.html
+
+## Tooling
+
+### gdbsx
+
+    Status, x86: Supported
+
+Debugger to debug ELF 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
+
+### Guest serial sonsole
+
+    Status: Supported
+
+Logs key hypervisor and Dom0 kernel events to a file
+
+### xentrace
+
+    Status, x86: Supported
+
+Tool to capture Xen trace buffer data
+
+### gcov
+
+    Status: Supported, Not security supported
+
+## Memory Management
+
+### Memory Ballooning
+
+    Status: Supported
+
+### Memory Sharing
+
+    Status, x86 HVM: Preview
+    Status, ARM: Preview
+
+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
+
+### Alternative p2m
+
+    Status, x86: Preview
+
+Allows external monitoring of hypervisor memory using Intel EPT by allowing to 
maintain multiple physical memory to machine physical mappings
+
+[XXX Should this be x86/Alternative p2m?]
+
+## 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
+
+The default scheduler, which is a weighted proportional fair share virtual CPU 
scheduler.
+
+### Credit2 Scheduler
+
+    Status: Supported
+
+Credit2 is 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, Not security supported
+
+A periodically repeating fixed timeslice scheduler. Multicore support is not 
yet implemented.
+
+### Null Scheduler
+
+    Status: Experimental
+
+A very simple, very static scheduling posicy 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
+
+## Scalability
+
+### 1GB/2MB super page support
+
+    Status: Supported
+
+### x86/Deliver events to PVHVM guests using Xen event channels
+
+    Status: Supported
+
+### Fair locks (ticket-locks)
+
+    Status: Supported
+
+[XXX Is this host ticket locks?  Or some sort of guest PV ticket locks?  If 
the former it doesn't make any sense to call it 'supported' because they're 
either there or not.]
+
+## High Availability and Fault Tolerance
+
+### Live Migration, Save & Restore
+
+    Status, x86: Supported
+
+### Remus Fault Tolerance
+
+    Status: Experimental
+
+### COLO Manager
+
+    Status: Experimental
+
+### vMCE
+
+    Status, x86: Supported
+
+Forward Machine Check Exceptions to Appropriate guests
+
+## Virtual driver support, guest side
+
+### Blkfront
+
+    Status, Linux: Supported
+    Status, FreeBSD: Supported, Security support external
+    Status, Windows: Supported [XXX]
+
+Guest-side driver capable of speaking the Xen PV block protocol
+
+### Netfront
+
+    Status, Linux: Supported
+    Status, FreeBSD: Supported, Security support external
+    States, Windows: Supported [XXX]
+
+Guest-side driver capable of speaking the Xen PV networking protocol
+
+### Xen Framebuffer
+
+    Status, Linux (xen-fbfront): Supported
+
+Guest-side driver capable of speaking the Xen PV Framebuffer protocol
+
+[XXX FreeBSD? NetBSD?]
+
+### Xen Console
+
+    Status, Linux (hvc_xen): Supported
+
+Guest-side driver capable of speaking the Xen PV console protocol
+
+[XXX FreeBSD? NetBSD? Windows?]
+
+### Xen PV keyboard
+
+    Status, Linux (xen-kbdfront): Supported
+
+Guest-side driver capable of speaking the Xen PV keyboard protocol
+
+### Xen PVUSB protocol
+
+    Status, Linux: Supported
+
+### Xen PV SCSI protocol
+
+    Status, Linux: [XXX]
+
+### Xen TPMfront
+
+    Status, Linux (xen-tpmfront): Preview
+
+Guest-side driver capable of speaking the Xen PV TPM protocol
+
+### Xen 9pfs frontend
+
+   Status, Linux: Preview
+
+Guest-side driver capable of speaking the Xen 9pfs protocol
+
+### PVCalls frontend
+
+   Status, Linux: Preview
+
+Guest-side driver capable of making pv system calls
+
+## Virtual device support, host side
+
+### Blkback
+
+    Status, Linux (blkback): Supported
+    Status, FreeBSD (blkback): Supported
+    Status, QEMU (xen_disk): Supported
+    Status, Blktap2: Deprecated
+
+Host-side implementations of the Xen PV block protocol
+
+### Netback
+
+    Status, Linux (netback): Supported
+    Status, FreeBSD (netback): Supported
+    Status, QEMU (xen_nic): Experimental
+
+Host-side implementations of Xen PV network protocol
+
+### Xen Framebuffer
+
+    Status, Linux: Supported
+    Status, QEMU: Supported
+
+Host-side implementaiton of the Xen PV framebuffer protocol
+
+### Xen Console
+
+    Status, Linux: Supported
+    Status, QEMU: Supported
+
+Host-side implementation of the Xen PV console protocol
+
+### Xen PV keyboard
+
+    Status, Linux: Supported
+    Status, QEMU: Supported
+
+Host-side implementation fo the Xen PV keyboard protocol
+
+### Xen PV USB
+
+    Status, Linux: Experimental
+    Status, QEMU: Supported
+
+Host-side implementation of the Xen PV USB protocol
+
+### Xen PV SCSI protocol
+
+    Status, Linux: [XXX]
+
+### Xen PV TPM
+
+    Status, Linux: Supported
+
+### Xen 9pfs
+
+    Status, QEMU: Preview
+
+### PVCalls
+
+    Status, Linux: Preview
+
+### Online resize of virtual disks
+
+    Status: Supported
+
+## Security
+
+### Driver Domains
+
+    Status: Supported
+
+### Device Model Stub Domains
+
+    Status: Supported, with caveats
+
+Vulnerabilities of a device model stub domain to a hostile driver domain are 
excluded from security support.
+
+### KCONFIG Expert
+
+    Status: Experimental
+
+### Live Patching
+
+    Status: Supported, x86 only
+
+Compile time disabled
+
+### Virtual Machine Introspection
+
+    Status: Supported, x86 only
+
+### XSM & FLASK
+
+    Status: Experimental
+
+Compile time disabled
+
+### XSM & FLASK support for IS_PRIV
+
+    Status: Experimental
+
+Compile time disabled
+
+### vTPM Support
+
+    Status: Supported, x86 only
+
+### Intel/TXT ???
+
+    Status: ???
+
+TXT-based integrity system for the Linux kernel and Xen hypervisor
+
+[XXX]
+
+## Hardware
+
+### x86/Nested Virtualization
+
+    Status: Experimental
+
+Running a hypervisor inside an HVM guest
+
+### 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/Physical CPU Hotplug
+
+    Status: Supported
+
+### x86/Physical Memory Hotplug
+
+    Status: Supported
+
+### x86/PCI Passthrough PV
+
+    Status: Supported, Not security supported
+
+PV passthrough cannot be done safely.
+
+[XXX Not even with an IOMMU?]
+
+### x86/PCI Passthrough HVM
+
+    Status: Supported, with caveats
+
+Many hardware device and motherboard combinations are not possible to use 
safely.
+The XenProject will support bugs in PCI passthrough for Xen,
+but the user is responsible to ensure that the hardware combination they use
+is sufficiently secure for their needs,
+and should assume that any combination is insecure
+unless they have reason to believe otherwise.
+
+### ARM/Non-PCI device passthrough
+
+    Status: Supported
+
+### x86/Advanced Vector eXtension
+
+    Status: Supported
+
+### Intel Platform QoS Technologies
+
+    Status: Preview
+
+### ARM/ACPI (host)
+
+    Status: Experimental
+
+### ARM/SMMU
+
+    Status: Supported, with caveats
+
+Only ARM SMMU hardware is supported; non-ARM SMMU hardware is not supported.
+
+### ARM/ITS
+
+    Status: experimental
+
+[XXX What is this?]
+
+### ARM: 16K and 64K pages in guests
+    Status: Supported, with caveats
+
+No support for QEMU backends in a 16K or 64K domain.
+
+
+# Format and definitions
+
+This file contains prose, and machine-readable fragments.
+The data in a machine-readable fragment relate to
+the section and subection in which it is fine.
+
+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.
+
+### Restrictions
+
+This is a summary of any restrictions which apply,
+particularly to functional or security support.
+
+Full details of restrictions may be provided in the prose
+section of the feature entry,
+if a Restrictions tag is present.
+
+### Limit-Security
+
+For size limits.
+This figure shows the largest configuration which will receive
+security support.
+This does not mean that such a configuration will actually work.
+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,
+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).
+    Links to that organization's security process
+    will be given in the description.
+
+  * **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.
-- 
2.14.1


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