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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 31 Aug 2017, George Dunlap wrote:
> +### Direct-boot kernel image format
> +
> +    Supported, x86: bzImage
> +    Supported, ARM32: zImage
> +    Supported, ARM64: Image [XXX - Not sure if this is correct]

On ARM64 it's called Image.gz.


> +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?]

No, the technology could be available on ARM.


> +## 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.

Can we say more than Experimental? I think it should be at least Tech
Preview.


> +### 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

Please write "Xen Framebuffer Frontend" in the title.


> +    Status, Linux (xen-fbfront): Supported
> +
> +Guest-side driver capable of speaking the Xen PV Framebuffer protocol
> +
> +[XXX FreeBSD? NetBSD?]
> +
> +### Xen Console

Please write frontend in the title


> +    Status, Linux (hvc_xen): Supported
> +
> +Guest-side driver capable of speaking the Xen PV console protocol
> +
> +[XXX FreeBSD? NetBSD? Windows?]
> +
> +### Xen PV keyboard

Please write frontend in the title


> +    Status, Linux (xen-kbdfront): Supported
> +
> +Guest-side driver capable of speaking the Xen PV keyboard protocol
> +
> +### Xen PVUSB protocol

Please write frontend in the title


> +    Status, Linux: Supported
> +
> +### Xen PV SCSI protocol

Please write frontend in the title


> +
> +    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

I suggest to Deprecate xen_nic


> +Host-side implementations of Xen PV network protocol
> +
> +### Xen Framebuffer

Please write backend in the title


> +    Status, Linux: Supported
> +    Status, QEMU: Supported
> +
> +Host-side implementaiton of the Xen PV framebuffer protocol
> +
> +### Xen Console
> +

Please write backend in the title


> +    Status, Linux: Supported
> +    Status, QEMU: Supported
> +
> +Host-side implementation of the Xen PV console protocol
> +
> +### Xen PV keyboard
> +

Please write backend in the title


> +    Status, Linux: Supported
> +    Status, QEMU: Supported
> +
> +Host-side implementation fo the Xen PV keyboard protocol
> +
> +### Xen PV USB
> +

Please write backend in the title


> +    Status, Linux: Experimental
> +    Status, QEMU: Supported
> +
> +Host-side implementation of the Xen PV USB protocol
> +
> +### Xen PV SCSI protocol

Please write backend in the title


> +
> +    Status, Linux: [XXX]
> +
> +### Xen PV TPM

Please write backend in the title


> +
> +    Status, Linux: Supported
> +
> +### Xen 9pfs

Please write backend in the title


> +
> +    Status, QEMU: Preview
> +
> +### PVCalls

Please write backend in the title


> +
> +    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

This should probably be x86/vTPM. TPM, the way we are discussing it, is
an x86-only implementation. ARM-based alternatives are not called TPM
AFAIK.



> +### Intel/TXT ???

Same here


> +    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?]

A particularly complex extension to the interrupt controller.


> +### 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