[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [PATCH v3 19/18] charter: full diff of proposed changes
Full updated version attached below. As all comments on the previous
ones were minor, I will now start a ballot to request a special majority
vote.
---
diff --git a/charter.html b/charter.html
index 7006009..69b711c 100644
--- a/charter.html
+++ b/charter.html
@@ -17,7 +17,7 @@
These guests need networks, storage, consoles and similar but non-virtualization-aware standard devices cannot be shared, or guests may not be permitted to access host devices at all. The simplest solution is to emulate a device expected by the guest operating system, but this can be slow and/or complicated. As most operating systems have facilities for adding drivers for new physical hardware, we can use the same facilities to add drivers for devices which are easier and/or more efficient to implement in software.
</p>
<p>
- As every hypervisor is different, they tend to implement hypervisor-specific devices, requiring every guest to support a new device for that environment. For example, Linux currently supports completely separate drivers for eight different virtualization platforms, with most drivers being sub-optimal. In 2007, an attempt was made to implement a hypervisor and OS-agnostic device model in Linux guests and the KVM hypervisor over the standard PCI bys. This is now also supported by the VirtualBox hypervisor (2010) and FreeBSD guests (2011).
+ As every hypervisor is different, they tend to implement hypervisor-specific devices, requiring every guest to support a new device for that environment. For example, in 2013 Linux supported completely separate drivers for eight different virtualization platforms, with most drivers being sub-optimal. In 2007, an attempt was made to implement a hypervisor and OS-agnostic device model in Linux guests and the KVM hypervisor over the standard PCI bus. This is now supported by multiple other hypervisors.
</p>
<p>
A Draft Specification
@@ -35,19 +35,47 @@
A 1.0 Specification
</p>
<p>
- Our goal is to keep the good, discard the bad, and make the ugly optional. In particular, we will try not to break too much, and ensure it's possible for devices to support both 1.0 compliant and legacy guest drivers.
+ With the 1.0 Specification, the goal of the OASIS Virtual I/O Device (VIRTIO) Technical Committee was to keep the good, discard the bad, and make the ugly optional. The "Virtio PCI Card Specification" 0.9.5, was used as a starting point (referred to as "legacy"). In particular, the Committee tried not to break too much, and (with the exception of the mmio transport) the specification is designed to make it possible for devices to support both 1.0 compliant and legacy guest drivers.
+ </p>
+ <p>
+ 1.X Specifications
+ </p>
+ <p>
+ Support for new technologies often calls for extensions to the standard. For example,
+ as technologies such as nested virtualization and hardware-based
+ implementations of VIRTIO devices became popular, these devices are no longer
+ necessarily part of a hypervisor. This in turn requires a strong commitment to
+ driver and device compatibility, as well as to driver and device security.
+ With the 1.1, 1.2 and future revisions of the Specification, we aim to evolve the VIRTIO standard further, addressing such new requirements while both continuing to honor the goals of the 1.0 Specification and including new objectives.
</p>
</li>
<li>
Scope
<p>
- The "Virtio PCI Card Specification" 0.9.5, minus the Appendix H, shall be used as a starting point (referred to as "legacy"). Note that we expect the final output of this TC to be incompatible with that specification, though it will be possible for virtual devices to support both legacy and modern guest drivers.
+ The TC will develop and produce versions 1.X of the OASIS Virtual I/O Device (VIRTIO) OASIS Standard by refining and documenting existing implementations and practice.
</p>
<p>
- The TC will produce an OASIS Standard by refining and documenting existing implementations and practice. After publication of the initial OASIS Standard, the TC may choose to develop a Version 2.0 standard that builds on lessons learned and identified trends and that may result in a significantly different architecture and approach. Until then, the TC shall not throw out the baby with the bathwater, boil the ocean, or embark on a PhD research topic.
+ The TC will also act as a registrar for the list of reserved device numbers for non-specified device types, as well as the list of reserved feature numbers for non-specified features for each device type.
</p>
<p>
- The TC will consider one or more buses for virtual devices, including PCI. It will consider various kinds of devices, including network devices. Each part of the OASIS Standard will be considered in terms of portability, simplicity, least-surprise for driver authors, extensibility and performance. In particular, the effect of future radical extensions (such as layout changes) will be considered.
+ Starting from version 1.1, each version of the specification shall be used as a starting point for the development of the next version of the specification.
+ </p>
+ <p>
+ Note that we expect the output of this TC to be compatible with all previous versions of the specification, such that
+ compliant devices and drivers remain compliant with future versions of the specification.
+ In particular, special care will be taken such that drivers compliant with a certain version of the specification can also support devices compliant with all past versions of the specification, and vice versa.
+ </p>
+ <p>
+ When correcting defects in the specification, e.g. by adding new normative statements, the TC will
+ also take special care to avoid declaring existing working implementations non-compliant
+ as far as possible.
+ The TC will take into account factors such as existance and prevalence of implementations with the
+ defective behaviour and whether these implementations are working and robust.
+ When in doubt, the TC will err on the conservative side, such as by adding new feature bits
+ or by making the corrected behaviour recommended but not mandatory.
+ </p>
+ <p>
+ The TC will consider one or more buses for virtual devices, including PCI. It will consider various kinds of devices, including network devices. Each part of the OASIS Standard will be considered in terms of portability, simplicity, least-surprise for driver authors, security, compatibility, extensibility and performance. In particular, the effect of future extensions (such as layout changes) will be considered.
</p>
</li>
<li>
@@ -62,52 +90,43 @@
<li>
Specifically for virtio over mmio.
</li>
+ <li>
+ Specifically for virtio over channel I/O.
+ </li>
<li>
Specifically for other transports as decided by TC.
</li>
</ol>
</li>
<li>
- Specification of device-specific configuration.
+ Specification of device-specific features, configuration and operation.
<ol class="vanilla-lower-alpha">
- <li>
- For network devices.
+ <li>
+ Definition for multiple specified device types.
</li>
<li>
- For block storage devices.
+ Normative requirements for specified device types.
</li>
<li>
- For entropy devices.
+ List of reserved feature numbers for non-specified features for each device type. (This section is likely to see ongoing maintenance).
</li>
<li>
- For console devices.
- </li>
- <li>
- For memory ballooning devices.
- </li>
- <li>
- For SCSI endpoint devices.
- </li>
- <li>
- Non-normative advice for designing new device types.
- </li>
- <li>
- List of reserved device numbers for non-specified device types. (This section is likely to see ongoing maintenance before 2.0).
- </li>
- <li>
- List of reserved feature numbers for non-specified features for each device type. (This section is likely to see ongoing maintenance before 2.0).
+ List of reserved device numbers for non-specified device types. (This section is likely to see ongoing maintenance).
</li>
</ol>
</li>
<li>
- Non-normative code examples for operation of guest/host side of buffers.
+ Non-normative code examples for operation of driver/device side of buffers.
</li>
<li>
- Non-normative guide for creating devices which also support previous mode(s).
+ Non-normative advice for designing new device types.
+ </li>
+ <li>
+ Non-normative guidance for creating devices and drivers which also support a legacy mode.
</li>
</ol>
<p>
- We anticipate deliverables (1) and (2) to be a single work, and (3) and (4) to be separate works. The projected delivery dates are 12 to 16 months after the first meeting.
+ The projected delivery dates for the specifications are every 12 to 16 months.
</p>
</li>
<li>
@@ -119,7 +138,7 @@
<li>
Audience
<p>
- Developers of hypervisors and device driver authors.
+ Developers of devices, hypervisors and device drivers.
</p>
</li>
<li>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]