d519c224ba69 & 20 Jun 2019 & Stefan Hajnoczi & { content: reserve virtio device ID for file system devices


Reserve device ID 26 for virtio-fs devices.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/31}

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
9454b568c29b & 20 Jun 2019 & Pankaj Gupta & { content: reserve device ID for virtio-pmem devices


We need a device ID for virtio-pmem devices. As 25 is requested by
audio device and 26 is requested by virtio-fs, so requesting
next available(27). Also, updated the previously requested github
issue[1] for voting.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/38}

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Pankaj Gupta <pagupta@redhat.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
efd4028b7aec & 25 Jul 2019 & Dr. David Alan Gilbert & { shared memory: Define shared memory regions


Define the requirements and idea behind shared memory regions.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/40}

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Basic Facilities of a Virtio Device / Shared Memory Regions}.
 } \\
\hline
39dfc8afc0b9 & 25 Jul 2019 & Dr. David Alan Gilbert & { pci: Define id field


For the virtio-fs device we require multiple large shared memory

regions.  Differentiate these by an 'id' field in the base capability.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/40}

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
 } \\
\hline
8100dcfcd622 & 25 Jul 2019 & Dr. David Alan Gilbert & { pci: Define virtio_pci_cap64


Define 'virtio_pci_cap64' to allow capabilities to describe
memory regions larger than, or with an offset larger than 4GiB.

This will be used by the shared memory region capability.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/40}

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
 } \\
\hline
855ad7af2bd6 & 25 Jul 2019 & Dr. David Alan Gilbert & { shared memory: Define PCI capability


Define the PCI capability used for enumerating shared memory regions.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/40}

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Shared memory capability}.
 } \\
\hline
2dd2d468f69b & 25 Jul 2019 & Dr. David Alan Gilbert & { shared memory: Define mmio registers


Define an MMIO interface to discover and map shared
memory regions.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/40}

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over MMIO / MMIO Device Register Layout}.
 } \\
\hline
4237d22cd5b1 & 08 Sep 2019 & Nikos Dragazis & { content: fix typo


Signed-off-by: Nikos Dragazis <ndragazis@arrikto.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
 } \\
\hline
1571d741f300 & 08 Sep 2019 & Dr. David Alan Gilbert & { shared memory: Typo fix


Fix double hex in SHM*High defs.

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over MMIO / MMIO Device Register Layout}.
 } \\
\hline
7a25d74962d3 & 08 Sep 2019 & Tiwei Bie & { content: fix typo in feature bit name


Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/46}

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

See \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue / VLAN Filtering}.
 } \\
\hline
6aecd69eb90b & 08 Sep 2019 & Tiwei Bie & { content: explicitly document the VLAN filtering as best-effort


Similar to the MAC address based filtering, the VLAN filtering
is also best-effort in implementations, but it's not quite clear
in the spec. So document this behaviour explicitly to reflect
the way implementations behave.

Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>

Acked-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/47}

See \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue / VLAN Filtering}.
 } \\
\hline
29540779e4fd & 25 Sep 2019 & Stefan Hajnoczi & { content: add virtio file system device


The virtio file system device transports Linux FUSE requests between a
FUSE daemon running on the host and the FUSE driver inside the guest.

The actual FUSE request definitions are not duplicated in the virtio
specification, similar to how virtio-scsi does not document SCSI
command details.  FUSE request definitions are available here:
\url{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/fuse.h}

This patch documents the core virtio file system device, which is
functional but lacks the DAX feature introduced in the next patch.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/49}

See \ref{sec:Device Types / File System Device}.
 } \\
\hline
ef5a7f405b95 & 25 Sep 2019 & Stefan Hajnoczi & { virtio-fs: add DAX window


Describe how shared memory region ID 0 is the DAX window and how
FUSE_SETUPMAPPING maps file ranges into the window.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/49}

See \ref{sec:Device Types / File System Device / Device Operation / Device Operation: DAX Window},
and \ref{sec:Device Types / File System Device / Security Considerations}.
 } \\
\hline
1e30753d53d2 & 12 Oct 2019 & Jan Kiszka & { Fix \textasciicircum= in example code


Trying to escaping \textasciicircum\space here only leaves the backslash in the output.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Basic Facilities of a Virtio Device / Packed Virtqueues / Supplying Buffers to The Device / Implementation Example},
and \ref{sec:Basic Facilities of a Virtio Device / Packed Virtqueues / Receiving Used Buffers From The Device}.
 } \\
\hline
f9bed5bcb25e & 12 Oct 2019 & Jan Kiszka & { Lift "Driver Notifications" to section level


Currently, it slips under the Packed Virtqueues section while it is not
specific to this format.

At this chance, capitalize "Notifications".

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Virtqueues / Driver notifications}.
 } \\
\hline
8f2c4e03eae8 & 27 Oct 2019 & Eugenio Pérez & { block: Add multiqueue


The spec miss that field. Add the field, some description around.

I've followed the network device's multiqueue mentions, and copied /
adapted when needed.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/50}

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / Block Device},
\ref{sec:Device Types / Block Device / Virtqueues},
\ref{sec:Device Types / Block Device / Feature bits},
\ref{sec:Device Types / Block Device / Device configuration layout},
\ref{sec:Device Types / Block Device / Device Initialization},
and \ref{sec:Device Types / Block Device / Device Operation}.
 } \\
\hline
f1f2f85c1482 & 27 Oct 2019 & Jan Kiszka & { Console Device: Add a missing word


Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

See \ref{sec:Device Types / Console Device / Device Operation}.
 } \\
\hline
da17c7fc4e12 & 27 Oct 2019 & Paolo Bonzini & { virtio_pci_common_cfg: fix field name


The field is named config_msix_vector in the rest of the document,
use the same name in the struct.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/41}

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Common configuration structure layout}.
 } \\
\hline
f459b9e0ea60 & 27 Oct 2019 & Eugenio Pérez & { virtio-blk: typo: Capitalization in Device Initialization item


Signed-off-by: Eugenio Pérez <eperezma@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/51}

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

See \ref{sec:Device Types / Block Device / Device Initialization}.
 } \\
\hline
30d8e1ad22f7 & 27 Oct 2019 & Philipp Hahn & { Balloon: Fix Memory Statistics structure size


5.5.6.3 Memory Statistics: 6 -> 10 byte

> Within the buffer, statistics are an array of 6-byte entries.

                                                \textasciicircum

> Each statistic consists of a 16 bit tag and a 64 bit value.

...

> struct virtio_balloon_stat .

...

>         le16 tag;

>         le64 val;

> \} __attribute__((packed));

If my calculation is right that is a (16 + 64) = 80 bits which is a
10-byte sized entry - not 6-byte.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/45}

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / Memory Balloon Device / Device Operation / Memory Statistics}.
 } \\
\hline
acfe7bd5bcbe & 27 Oct 2019 & Michael S. Tsirkin & { README.md: document the minor cleanups standing rule


Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

 } \\
\hline
a610121f250b & 24 Nov 2019 & Jan Kiszka & { virtio-mmio: Rename remaining QueueAvail/Used references


These have been changed in ae98c6bc21bc. Convert the rest.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/52}

See \ref{sec:Virtio Transport Options / Virtio Over MMIO / MMIO Device Register Layout}.
 } \\
\hline
4be5d38ad692 & 24 Nov 2019 & Stefan Fritsch & { Fix typo


It's balloon, not ballon.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Stefan Fritsch <sf@sfritsch.de>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / Memory Balloon Device / Virtqueues}.
 } \\
\hline
3109be870170 & 24 Nov 2019 & Paolo Bonzini & { Reserve id for virtio-audio device


Project ACRN has a virtio-audio device. Unfortunately, the id they are using is
already reserved in the virtio specification, but it is nevertheless useful to
have one.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/42}

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
4f1981a1ff46 & 24 Nov 2019 & Vitaly Mireyno & { virtio-net: Add support for correct hdr_len field.


Includes device implementation note for using hdr_len

Signed-off-by: Vitaly Mireyno <vmireyno@marvell.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/57}

See \ref{sec:Device Types / Network Device / Feature bits},
and \ref{sec:Device Types / Network Device / Device Operation / Packet Transmission}.
 } \\
\hline
2c77526beb13 & 24 Nov 2019 & Cornelia Huck & { virtio-net: add missing articles for new hdr_len feature


And tweak a sentence slightly.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

See \ref{sec:Device Types / Network Device / Device Operation / Packet Transmission}.
 } \\
\hline
8c6acac22a99 & 27 Nov 2019 & Huang Yang & { Add virtio rpmb device specification


Add virtio RPMB (Replay Protected Memory Block) device documentation to
spec.

Signed-off-by: Yang Huang <yang.huang@intel.com>

Reviewed-by: Bing Zhu <bing.zhu@intel.com>

Reviewed-by: Tomas Winkler <tomas.winkler@intel.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/53}

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / RPMB Device}.
 } \\
\hline
e8ba780bd7ab & 27 Nov 2019 & Huang Yang & { Reserve device id 28 for virtio RPMB device


Signed-off-by: Huang Yang <yang.huang@intel.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/58}

See \ref{sec:Device Types}.
 } \\
\hline
356aeeb40d7a & 20 Jan 2020 & Michael S. Tsirkin & { content: add vendor specific cfg type


Vendors might want to add their own capability in the PCI capability
list. However, Virtio already uses the vendor specific capability ID
(0x09) for its own purposes.

Provide a structure for vendor specific extensions.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/62}

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities},
and \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Vendor data capability}.
 } \\
\hline
50049af040d4 & 20 Jan 2020 & Michael S. Tsirkin & { virtio_pci_cap64: bar/BAR cleanups


When we mean PCI register we should say BAR.
When we mean a virtio config register we should say \textbackslash field\{cap.bar\}.

Finally, offset_hi/length_hi are not within the cap structure.

Tweak wording slightly: "A,B,C" are fields, there's no need
to say that.

Reported-by: Christophe de Dinechin <cdupontd@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities},
and \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Shared memory capability}.
 } \\
\hline
b6e992c7af88 & 20 Jan 2020 & Yuri Benditovich & { virtio-net: define support for receive-side scaling


Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/48}
Added support for RSS receive steering mode.

Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / Network Device / Virtqueues},
\ref{sec:Device Types / Network Device / Feature bits},
\ref{sec:Device Types / Network Device / Feature bits / Feature bit requirements},
\ref{sec:Device Types / Network Device / Device configuration layout},
and \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue}.
 } \\
\hline
8361dd6eb0f4 & 20 Jan 2020 & Michael S. Tsirkin & { virtio-net: receive-side scaling


Typo/grammar fixes as suggested by Cornelia (and a couple
noticed by myself).

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / Network Device / Device configuration layout},
and \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue}.
 } \\
\hline
1efcda892193 & 20 Jan 2020 & Michael S. Tsirkin & { virtio-net: missing "." for feature descriptions


At end of each sentence, for consistency.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / Network Device / Feature bits}.
 } \\
\hline
652237ea2839 & 20 Jan 2020 & Jean-Philippe Brucker & { Add virtio-iommu device specification


The IOMMU device allows a guest to manage DMA mappings for physical,
emulated and paravirtualized endpoints. Add device description for the
virtio-iommu device and driver. Introduce PROBE, ATTACH, DETACH, MAP and
UNMAP requests, as well as translation error reporting.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/37}

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / IOMMU Device}.
 } \\
\hline
6914d2df75ec & 28 Jan 2020 & Keiichi Watanabe & { content: Reserve device ID for video encoder and decoder device


Reserve device ID 30 for video encoder device and 31 for video decoder device.

Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Acked-by: Gerd Hoffmann <kraxel@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
d7e91b5469fb & 28 Jan 2020 & Michael S. Tsirkin & { virtio-rng: fix device/driver confusion


The point of rng is to give data to driver so of course
all buffers are driver readable. What shouldn't be there
is device readable buffers - this matches our terminology
elsewhere too (read/write-ability is from POV of device).

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/55}

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Pankaj Gupta <pagupta@redhat.com>

See \ref{sec:Device Types / Entropy Device / Device Operation}.
 } \\
\hline
da60923ce164 & 28 Jan 2020 & Michael S. Tsirkin & { content: document speed, duplex


Document as used by Linux.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/59}

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Network Device / Feature bits},
and \ref{sec:Device Types / Network Device / Device configuration layout}.
 } \\
\hline
61124330bf1c & 27 Feb 2020 & Gerd Hoffmann & { virtio-gpu: add 3d command overview


Add 3d commands to the command enumeration.
Add a section with a very short overview.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/65}

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / GPU Device / Device Operation / Device Operation: Request header},
and \ref{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq}.
 } \\
\hline
0c0dd715152c & 27 Feb 2020 & Gerd Hoffmann & { virtio-gpu: some edid clarifications


Add some notes about fetching the EDID information.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/64}

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / GPU Device / Device configuration layout},
and \ref{devicenormative:Device Types / GPU Device / Device Initialization}.
 } \\
\hline
f42cc75d0725 & 01 Mar 2020 & Michael S. Tsirkin & { virtio-net/rss: maximal -> maximum


Maximal can mean "local as opposed to a global maximum".  Rest of the
spec says maximum everywhere.  Let's be consistent.

Cc: Yuri Benditovich <yuri.benditovich@daynix.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / Network Device / Device configuration layout}.
 } \\
\hline
089bc5911dea & 04 May 2020 & Jean-Philippe Brucker & { virtio-iommu: Remove invalid requirement about padding


This reference to 'padding' is a leftover from a previous draft of the
virtio-iommu device. The field doesn't exist anymore, remove the
requirement.

Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / IOMMU Device / Device configuration layout}.
 } \\
\hline
e73c8cdf3e82 & 01 Sep 2020 & Anton Yakovlev & { virtio-snd: add virtio sound device specification


This patch proposes virtio specification for a new virtio sound device,
that may be useful in case when having audio is required but a device
passthrough or emulation is not an option.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/54}

Signed-off-by: Anton Yakovlev <anton.yakovlev@opensynergy.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / Network Device / Device configuration layout}.
 } \\
\hline
3f27648d9c66 & 01 Sep 2020 & Jan Kiszka & { split-ring: Demand that a device must not change descriptor entries


So far the spec only indirectly says that a descriptor table entry is
not modified by a device when processing it. Make this explicit by
adding it as normative requirement. Existing drivers already depend on
this.

See also \url{https://lists.oasis-open.org/archives/virtio-dev/201910/msg00057.html.}

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/56}

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Descriptor Table}.
 } \\
\hline
3353ed1c255a & 01 Sep 2020 & Yuri Benditovich & { virtio-net: Define per-packet hash reporting feature


Define respective feature bit for virtio-net.
Extend packet layout to populate hash value and type.
Move the definition of IP/TCP/UDP header fields to
calculate the hash out of RSS section to common network
device section.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/66}

Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / Network Device / Feature bits},
\ref{sec:Device Types / Network Device / Device configuration layout},
\ref{sec:Device Types / Network Device / Device Operation},
\ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets},
and \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue}.
 } \\
\hline
51cad55ea64d & 01 Sep 2020 & Johannes Berg & { reserve device ID for hwsim wireless simulation


The Linux mac80211-hwsim module currently allows simulation of
multiple wireless radios on a shared medium, and has an existing
API for this to work through a userspace implementation of the
medium simulation (e.g. implemented by wmediumd).

In order to simplify working with virtual machines and to enable
(time-compressed) simulation use cases, allocate a virtio device
ID to allow carrying this protocol over virtio in addition to
the current netlink sockets.

Since device ID 28 was previously requested, use 29.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/68}

See \ref{sec:Device Types}.
 } \\
\hline
832099d5df8c & 01 Sep 2020 & Vitaly Mireyno & { virtio-net: Fix VIRTIO_NET_F_GUEST_HDRLEN feature definition.


Fix driver and device requirements with regards to the VIRTIO_NET_F_GUEST_HDRLEN feature - 'hdr_len' must be accurate only for TSO/UFO packets.

Signed-off-by: Vitaly Mireyno <vmireyno@marvell.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/72}

See \ref{sec:Device Types / Network Device / Device Operation / Packet Transmission}.
 } \\
\hline
5d9444d699e5 & 01 Sep 2020 & Peter Hilber & { Reserve device ID 32 for SCMI device


Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/74}

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
68f66ff7a3d9 & 01 Sep 2020 & David Stevens & { content: define what an exported object is


Define a mechanism for sharing objects between different virtio
devices.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/76}

Signed-off-by: David Stevens <stevensd@chromium.org>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Basic Facilities of a Virtio Device / Exporting Objects}.
 } \\
\hline
162578b7e26c & 01 Sep 2020 & David Stevens & { virtio-gpu: add the ability to export resources


Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/76}

Signed-off-by: David Stevens <stevensd@chromium.org>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / GPU Device / Feature bits},
\ref{sec:Device Types / GPU Device / Device Operation / Device Operation: Request header},
and \ref{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq}.
 } \\
\hline
12d74846a6ee & 01 Sep 2020 & Petre Eftime & { content: Reserve virtio-nsm device ID


The NitroSecureModule is a device with a very stripped down
Trusted Platform Module functionality, which is used in the
context of a Nitro Enclave (see \url{https://lkml.org/lkml/2020/4/21/1020)}
to provide boot time measurement and attestation.

Since this device provides some critical cryptographic operations,
there are a series of operations which are required to have guarantees
of atomicity, ordering and consistency: operations fully succeed or fully
fail, including when some external events might interfere in the
process: live migration, crashes, etc; any failure in the critical
section requires termination of the enclave it is attached to, so
the device needs to be as resilient as possible, simplicity is
strongly desired.

To account for that, the device and driver are made to have very few
error cases in the critical path and the operations themselves can be
rolled back and retried if events happen outside the critical
area, while processing a request. The driver itself can be made very
simple and thus is easily portable.

Since the requests can be handled directly in the virtio queue, serving
most requests requires no additional buffering or memory allocations
on the host side.

Signed-off-by: Petre Eftime <epetre@amazon.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/81}

See \ref{sec:Device Types}.
 } \\
\hline
7a46ee550d70 & 01 Sep 2020 & David Hildenbrand & { conformance: make driver conformance list easier to read and maintain


Let's define it just like the device conformance list.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: David Hildenbrand <david@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Conformance / Conformance Targets}.
 } \\
\hline
9abf00ff4654 & 01 Sep 2020 & David Hildenbrand & { conformance: Reference RPMB Driver Conformance


We forgot to reference the driver conformance.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Cc: Yang Huang <yang.huang@intel.com>

Signed-off-by: David Hildenbrand <david@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

See \ref{sec:Conformance / Conformance Targets}.
 } \\
\hline
af6b93bfd9a0 & 01 Sep 2020 & David Hildenbrand & { Add virtio-mem device specification


The virtio memory device provides and manages a memory region in guest
physical address space. This memory region is partitioned into memory
blocks of fixed size that can either be in the state plugged or unplugged.

Specify the device configuration, initialization, and operation.
Introduce PLUG, UNPLUG, UNPLUG ALL and STATE requests.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/82}

Cc: teawater <teawaterz@linux.alibaba.com>

Signed-off-by: David Hildenbrand <david@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / Memory Device}.
 } \\
\hline
28ea45d8d79f & 11 Nov 2020 & Jie Deng & { content: Reserve device ID 34 for I2C adapter


Request the ID 34 for I2C adapter.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/85}

Signed-off-by: Jie Deng <jie.deng@intel.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
d44895cdadc0 & 11 Nov 2020 & Rob Bradford & { content: Reserve virtio-watchog device ID


Reserve an ID for a watchdog device which may be used to ensure that the
guest is responsive. This is equivalent of a hardware watchdog device
and will trigger the reboot of the guest if the the host does not
periodic ping from the the guest.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/87}

Signed-off-by: Rob Bradford <robert.bradford@intel.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
38448268eba0 & 11 Nov 2020 & Alexander Duyck & { content: Document balloon feature free page hints


Free page hints allow the balloon driver to provide information on what
pages are not currently in use so that we can avoid the cost of copying
them in migration scenarios. Add a feature description for free page hints
describing basic functioning and requirements.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/84}

Acked-by: Cornelia Huck <cohuck@redhat.com>

Reviewed-by: David Hildenbrand <david@redhat.com>

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Memory Balloon Device / Virtqueues},
\ref{sec:Device Types / Memory Balloon Device / Feature bits},
\ref{sec:Device Types / Memory Balloon Device / Device configuration layout},
\ref{sec:Device Types / Memory Balloon Device / Device Initialization},
and \ref{sec:Device Types / Memory Balloon Device / Device Operation / Free Page Hinting}.
 } \\
\hline
4749f03e72f8 & 11 Nov 2020 & Alexander Duyck & { content: Document balloon feature page poison


Page poison provides a way for the guest to notify the host that it is
initializing or poisoning freed pages with some specific poison value. As a
result of this we can infer a couple traits about the guest:

1. Free pages will contain a specific pattern within the guest.
2. Modifying free pages from this value may cause an error in the guest.
3. Pages will be immediately written to by the driver when deflated.

There are currently no existing features that make use of this data. In the
upcoming feature free page reporting we will need to make use of this to
identify if we can evict pages from the guest without causing data
corruption.

Add documentation for the page poison feature describing the basic
functionality and requirements.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/84}

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Reviewed-by: David Hildenbrand <david@redhat.com>

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Memory Balloon Device / Feature bits},
\ref{sec:Device Types / Memory Balloon Device / Device configuration layout},
\ref{sec:Device Types / Memory Balloon Device / Device Initialization},
and \ref{sec:Device Types / Memory Balloon Device / Device Operation / Page Poison}.
 } \\
\hline
d917d4a8d552 & 11 Nov 2020 & Alexander Duyck & { content: Document balloon feature free page reporting


Free page reporting is a feature that allows the guest to proactively
report unused pages to the host. By making use of this feature is is
possible to reduce the overall memory footprint of the guest in cases where
some significant portion of the memory is idle. Add documentation for the
free page reporting feature describing the functionality and requirements.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/84}

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Reviewed-by: David Hildenbrand <david@redhat.com>

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Memory Balloon Device / Virtqueues},
\ref{sec:Device Types / Memory Balloon Device / Feature bits},
\ref{sec:Device Types / Memory Balloon Device / Device Initialization},
\ref{sec:Device Types / Memory Balloon Device / Device Operation / Page Poison},
and \ref{sec:Device Types / Memory Balloon Device / Device Operation / Free Page Reporting}.
 } \\
\hline
9164d35e4b2a & 13 Nov 2020 & Alexander Duyck & { content: Minor change to clarify free_page_hint_cmd_id


The original wording was a bit unclear and could have been misinterpreted
as indicating that VIRTIO_BALLOON_FREE_PAGE_HINT was read-only instead of
the field free_page_hint_cmd_id. To clarify that break it up into two
sentences making it clear that the field is only available if the feature
is negotiated, and that the field is read-only.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>

Acked-by: Michael S. Tsirkin <mst@redhat.com>

[CH: included under the minor cleanup rule]

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Memory Balloon Device / Device configuration layout}.
 } \\
\hline
b342d29aaf9f & 19 Nov 2020 & Stefan Hajnoczi & { virtio-blk: document VIRTIO_BLK_T_GET_ID


The VIRTIO_BLK_T_GET_ID request type was implemented in Linux and QEMU
in 2010.  It does not have a feature bit but devices respond with
VIRTIO_BLK_S_UNSUPP if a request type is unimplemented.

This patch documents the VIRTIO_BLK_T_GET_ID request type as currently
implemented in Linux and QEMU.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/63}

Suggested-by: Jan Kiszka <jan.kiszka@siemens.com>

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Block Device / Device Operation}.
 } \\
\hline
89e7eb5b9a76 & 19 Nov 2020 & Gurchetan Singh & { virtio-gpu: add resource create blob


Blob resources are size-based containers for host, guest, or
host+guest allocations.  These resources are designed with
mulit-process 3D support in mind, but also usable in virtio-gpu 2d
with guest memory.

Many hypercalls are reused, since a image view into the blob resource
is possible.

Blob resources are both forward and backward looking.

v2: Add TRANSFER_BLOB, SET_SCANOUT_BLOB, SCANOUT_FLUSH
v3: Remove SCANOUT_FLUSH and add notes
v4: Remove TRANSFER_BLOB for now.
v5: clarify interactions with ATTACH_BACKING / DETACH_BACKING.
    This is to preserve the possibility of guest swap-in and guest
    swap-out, while acknowledging this feature may never be implemented
    and may not be applicable for all future planned values of
    `blob_mem` or context types.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/86}

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>

Acked-by: Chia-I Wu <olvaffe@gmail.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / GPU Device / Feature bits},
and \ref{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq}.
 } \\
\hline
87fa6b5d8155 & 19 Nov 2020 & Gurchetan Singh & { virtio-gpu: add support for mapping/unmapping blob resources


This defines a virtgpu shared memory region, with the possibilty
of more in the future.  This is required to implement VK/GL coherent
memory semantics, among other things.

v6: disallow mapping an already mapped blob resource as a
    simplification

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/86}

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>

Acked-by: Gerd Hoffmann <kraxel@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / GPU Device / Device configuration layout},
and \ref{sec:Device Types / GPU Device / Device Operation}.
 } \\
\hline
2ff0d5c68af2 & 03 Dec 2020 & Vitaly Mireyno & { virtio-net: Add support for the flexible driver notification structure.


When the driver is required to send an available buffer notification
to the device, it sends the virtqueue number to be notified.

With this new feature, the device can optionally provide a per-virtqueue
value for the driver to use in driver notifications, instead of the
virtqueue number.

Some devices may benefit from this flexibility by providing, for example,
an internal virtqueue identifier, or an internal offset related to the
virtqueue number.

Changes from v8:
 * Incorporated comments for v8:
     - moved the feature from a network device to a global section
     - few minor changes

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/89}

Signed-off-by: Vitaly Mireyno <vmireyno@marvell.com>

[CH: wrapped overlong lines in commit message]

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Common configuration structure layout},
\ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Available Buffer Notifications},
and \ref{sec:Reserved Feature Bits}.
 } \\
\hline
bccdda7fb41a & 15 Dec 2020 & Michael S. Tsirkin & { typo: VIRTIO_NET_F_MAC_ADDR -> VIRTIO_NET_F_MAC


VIRTIO_NET_F_MAC_ADDR isn't defined. It's clear from context
that what is meant is VIRTIO_NET_F_MAC which controls whether
mac in config space is valid.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/90}

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Setting MAC Address Filtering}.
 } \\
\hline
87de7136382e & 15 Dec 2020 & David Hildenbrand & { virtio-mem: minor clarification regarding read-access to unplugged blocks


Let's clarify that we don't expect all DMA to work with unplugged blocks.
We really only give guarantees when reading from unplugged memory blocks
via the CPU, e.g., as done by Linux when creating a system dump via
kdump: the new kernel will copy the content of the old (crashed) kernel
via the CPU to user space, from where it will find its final destination
inside the dump file. Note that dumping via makedumpfile under Linux will
avoid reading unplugged blocks completely.

This is a preparation for device passthrough to VMs, whereby such
dedicated devices might not be able to read from unplugged memory blocks.

Let's document that this scenario is possible, and why this handling is
in place at all.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/91}

Cc: teawater <teawaterz@linux.alibaba.com>

Cc: Marek Kedzierski <mkedzier@redhat.com>

Cc: Michael S. Tsirkin <mst@redhat.com>

Cc: Cornelia Huck <cohuck@redhat.com>

Acked-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: David Hildenbrand <david@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Memory Device / Device Operation}.
 } \\
\hline
f725281ebba7 & 25 Jan 2021 & Jie Deng & { virtio-i2c: add the device specification


virtio-i2c is a virtual I2C adapter device. It provides a way
to flexibly communicate with the host I2C slave devices from
the guest.

This patch adds the specification for this device.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/88}

Signed-off-by: Jie Deng <jie.deng@intel.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Memory Device / Device Operation}.
 } \\
\hline
6ee5e4b54c8e & 26 Jan 2021 & Felipe Franciosi & { content: Fix driver/device wording on ISR bits


Section "ISR status capability" incorrectly worded that the bits part of
the register allows the device to distinguish between interrupt types.
It is the driver that needs access to that distinction, not the device.

Signed-off-by: Felipe Franciosi <felipe@nutanix.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / ISR status capability}.
 } \\
\hline
a17c29e2201b & 26 Jan 2021 & Alex Bennée & { virtio-gpu.tex: fix some UTF-8 damage


While building I got a warning about:

  ! Package utf8x Error: MalformedUTF-8sequence.

Fixes: 87fa6b5 ("virtio-gpu: add support for mapping/unmapping blob resources")

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq (3d)}.
 } \\
\hline
a306bf467850 & 09 Feb 2021 & Cornelia Huck & { clarify device reset


Properly specify that the method for the driver to request a
device reset is transport specific, and some action the device
has to take.

Reviewed-by: Jason Wang <jasowang@redhat.com>

Reviewed-by: Halil Pasic <pasic@linux.ibm.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/93}

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Basic Facilities of a Virtio Device / Device Status Field},
and \ref{sec:Basic Facilities of a Virtio Device / Device Reset}.
 } \\
\hline
f5fd3fca7e40 & 10 Feb 2021 & Peter Hilber & { content: reserve device ID 36 for CAN device


The CAN device sends and receives CAN (Controller Area Network)
messages. CAN is a communication protocol used in embedded systems.

Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>

Reviewed-by: Matti Möll <matti.moell@opensynergy.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/95}

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
30e6526f4d8e & 25 Feb 2021 & Cornelia Huck & { virtio-ccw: relax device requirement for revision-specific command rejection


The device is currently required to reject any command that is
not contained in the negotiated revision. Some implementations
did not actively check for the revision when processing a command;
retroactively changing these implementations can break existing
drivers.

Relaxing the rejection requirement to SHOULD makes these existing
device implementations compliant, and will not have any effect on
drivers that did not send any commands for wrong revisions.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/96}

Reviewed-by: Halil Pasic <pasic@linux.ibm.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Setting the Virtio Revision}.
 } \\
\hline
5e9a37b9a559 & 30 Mar 2021 & Enrico Granata & { Add lifetime metrics to virtio-blk


In many embedded systems, virtio-blk implementations are
backed by eMMC or UFS storage devices, which are subject to
predictable and measurable wear over time due to repeated write
cycles.

For such systems, it can be important to be able to track
accurately the amount of wear imposed on the storage over
time and surface it to applications. In a native deployments
this is generally handled by the physical block device driver
but no such provision is made in virtio-blk to expose these
metrics for devices where it makes sense to do so.

This patch adds support to virtio-blk for lifetime and wear
metrics to be exposed to the guest when a deployment of
virtio-blk is done over compatible eMMC or UFS storage.

Signed-off-by: Enrico Granata <egranata@google.com>

Fixes: \url{https://github.org/oasis-tcs/virtio-spec/issues/97}

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Block Device / Feature bits},
and \ref{sec:Device Types / Block Device / Device Operation}.
 } \\
\hline
80b54cfd10a3 & 30 Mar 2021 & Peter Hilber & { Add virtio SCMI device specification


This patch proposes a new virtio device for the Arm SCMI protocol.

The device provides a simple transport for the Arm SCMI protocol[1]. The
*S*ystem *C*ontrol and *M*anagement *I*nterface protocol allows speaking
to system controllers that allow orchestrating things like power
management, system state management and sensor access. The SCMI protocol
is used on SoCs where multiple cores and co-processors need access to
these resources.

The virtio transport allows making use of this protocol in virtualized
systems.

[1] \url{https://developer.arm.com/docs/den0056/c}

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/100}

Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Block Device / Device Operation}.
 } \\
\hline
f144e1847b95 & 06 Apr 2021 & Cornelia Huck & { title: list myself as Chair


Reflect my position in the document as well.

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Chair}.
 } \\
\hline
2d827b06874d & 14 Apr 2021 & Michael S. Tsirkin & { introduction: document \#define syntax


We use the C \#define syntax to refer to numeric values.
Let's document that.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/101}

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Constant Specifications}.
 } \\
\hline
b19f28ed5076 & 14 Apr 2021 & Hao Chen & { Reserve device id for parameter server


Use device ID 38

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/102}

Signed-off-by: Hao Chen <chenhaosjtuacm@google.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
22179bb0875c & 14 Apr 2021 & Hao Chen & { Reserve device id for audio policy device


Use device ID 39

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/103}

Signed-off-by: Hao Chen <chenhaosjtuacm@google.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
0711d7f18fa7 & 14 Apr 2021 & Cornelia Huck & { editorial: fix missing escape of '\#'


Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Constant Specifications}.
 } \\
\hline
3590a075a5fd & 03 May 2021 & Marcel Holtmann & { Reserve device id for Bluetooth device


Use device ID 40

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/108}

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
5749014a3d50 & 17 May 2021 & Yuri Benditovich & { virtio-net: fix mistake: segmentation -> fragmentation


The VIRTIO_NET_F_HOST_UFO feature fragments the packet. Only
first fragment has a UDP header.

Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Network Device / Device Operation / Packet Transmission}.
 } \\
\hline
d1471fdf932b & 17 May 2021 & Yuri Benditovich & { virtio-net: define USO feature


Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/104}

Unlike UFO (fragmenting the packet) the USO splits large UDP packet
to several segments when each of these smaller packets has UDP
header. In Linux see SKB_GSO_UDP_L4.

Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Network Device / Feature bits},
\ref{sec:Device Types / Network Device / Device Initialization},
and \ref{sec:Device Types / Network Device / Device Operation}.
 } \\
\hline
c6f7149d08a1 & 10 Jun 2021 & Joel Nider & { Make global flag names consistent


The global flags VIRTIO_F_EVENT_IDX and VIRTIO_F_INDIRECT_DESC
have inconsistent naming throughout the document. This change
removes the _RING designation from the flag names to make the
usage consistent.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/36}

Signed-off-by: Joel Nider <joel@nider.org>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Reserved Feature Bits},
\ref{sec:Packed Virtqueues / Driver and Device Event Suppression},
and \ref{sec:Basic Facilities of a Virtio Device / Packed Virtqueues / Supplying Buffers to The Device / Implementation Example}.
 } \\
\hline
a57fb86cdb03 & 10 Jun 2021 & Jiang Wang & { virtio-net: fix a display for num_buffers


One of num_buffers does not display correctly in
the html. The _b becomes a subscript b. This will
prevent it from being searched by using keyword num_buffers.

Fix it by adding a field keyword.

Signed-off-by: Jiang Wang <jiang.wang@bytedance.com>

Message-Id: <20210601172139.3725854-1-jiang.wang@bytedance.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets}.
 } \\
\hline
eddd5558447d & 17 Jun 2021 & Viresh Kumar & { Reserve device id for GPIO device


Use device ID 41

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/109}

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
63236f177602 & 08 Jul 2021 & Stefan Hajnoczi & { virtio-fs: add file system device to Conformance chapter


The file system device is not listed in the Conformance chapter. Fix
this.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Conformance / Conformance Targets}.
 } \\
\hline
3881c6b6fca9 & 08 Jul 2021 & Stefan Hajnoczi & { virtio-fs: add notification queue


The FUSE protocol allows the file server (device) to initiate
communication with the client (driver) using FUSE notify messages.
Normally only the client can initiate communication. This feature is
used to report asynchronous events that are not related to an in-flight
request.

This patch adds a notification queue that works like an rx queue in
other VIRTIO device types. The device can emit FUSE notify messages by
using a buffer from this queue.

This mechanism was designed by Vivek Goyal <vgoyal@redhat.com>.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/111}

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / File System Device / Virtqueues},
\ref{sec:Device Types / File System Device / Device configuration layout},
\ref{Device Types / File System Device / Device Initialization},
and \ref{sec:Device Types / File System Device / Device Operation}.
 } \\
\hline
eb6ef453af9b & 26 Jul 2021 & Cornelia Huck & { Reserved feature bits: fix missing verb


Reviewed-by: David Hildenbrand <david@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Reserved Feature Bits}.
 } \\
\hline
74822ee60ea9 & 27 Jul 2021 & Gaetan Harter & { content: fix a typo


Signed-off-by: Gaetan Harter <gaetan.harter@opensynergy.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue}.
 } \\
\hline
23d3f7a3a7c9 & 27 Jul 2021 & Gaetan Harter & { virtio-gpu: fix a typo


Signed-off-by: Gaetan Harter <gaetan.harter@opensynergy.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / GPU Device / Virtqueues}.
 } \\
\hline
247709f69260 & 29 Jul 2021 & Gaetan Harter & { virtio-crypto: fix missing conjunction and verb


The condition sentences were incomplete:
"guarantee THAT the size IS within the max_len".

Signed-off-by: Gaetan Harter <gaetan.harter@opensynergy.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Crypto Device / Device configuration layout}.
 } \\
\hline
1dc3ff82ab18 & 10 Aug 2021 & Max Gurtovoy & { virtio-blk: fix virtqueues accounting


Virtqueue index is zero based, thus virtqueue (N-1) refers to requestqN.

Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Block Device / Virtqueues}.
 } \\
\hline
b73b74aaca01 & 16 Aug 2021 & Alex Bennée & { virtio-rpmb: fix the description for multi-block reads


Previously the text said we fail if block count is set to 1 despite
language elsewhere in the text referring to:

  "For RPMB read request, one virtio buffer including request command
  and the subsequent [block_count] virtio buffers for response data
  are placed in the queue."

and the existence of both max_wr_cnt and max_rd_cnt configuration
variables certainly implying devices should be able to handle
multi-block reads just like writes.

Fix the description as well as format the steps as an enumerated list
to match the style of the previous section describing write handling.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/113}

Reported-by: Ruchika Gupta <ruchika.gupta@linaro.org>

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / RPMB Device / Device Operation / Device Operation: Request Queue}.
 } \\
\hline
9547f52400c6 & 18 Aug 2021 & Viresh Kumar & { virtio-gpio: Add the device specification


virtio-gpio is a virtual GPIO controller. It provides a way to flexibly
communicate with the host GPIO controllers from the guest.

Note that the current implementation doesn't provide atomic APIs for
GPIO configurations. i.e. the driver (guest) would need to implement
sleep-able versions of the APIs as the guest will respond asynchronously
over the virtqueue.

This patch adds the specification for it.

Based on the initial work posted by:
"Enrico Weigelt, metux IT consult" <lkml@metux.net>.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/110}

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / GPIO Device}.
 } \\
\hline
4b65fb2f74fa & 17 Sep 2021 & Viresh Kumar & { virtio-gpio: Specify character encoding for gpio names


Specify 7-bit ASCII character encoding for GPIO names strings.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/115}

Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / GPIO Device / requestq Operation / Get Line Names}.
 } \\
\hline
c8338338edaf & 17 Sep 2021 & Michael S. Tsirkin & { virtio-net: fix speed, duplex


Speed values have an extra "f" - they are 32 bit, not 36 bit.  Duplex is
implemented in Linux and QEMU as 0x01 for full duplex and 0x00 for half
duplex.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/75}

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Network Device / Device configuration layout}.
 } \\
\hline
a4bb00171010 & 24 Sep 2021 & Gurchetan Singh & { virtio-gpu: clarify spec regarding capability sets


Capability sets will be used as a proxy for the context type,
so add more detail regarding their use.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/117}

Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / GPU Device / Device configuration layout},
and \ref{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq}.
 } \\
\hline
aad2b6f3620e & 24 Sep 2021 & Gurchetan Singh & { virtio-gpu: add context init support


This brings explicit context initialization and different types
to virtio-gpu.

In the past, VIRTIO_GPU_F_VIRGL meant the virglrenderer support.
With VIRTIO_GPU_F_VIRGL + VIRTIO_GPU_F_CONTEXT_INIT, this means
generic 3D virtualization defined by the context type.  It's
entirely possible the virglrenderer project isn't available on
the host in this scenario.  The VIRTIO_GPU_F_VIRGL naming
convention is kept since it's easier to redefine the meaning
rather than changing header files.

The context type is associated an particular capset id.  Virgl
has two capsets due a prior bug, but for other cases the 1:1
mapping between context type and capset id is valid.

In addition, fencing needs to be fixed to accomodate multiple
context types.  In the past, there was one global timeline
associated witht the OpenGL rendering.  Now, there are multiple
timelines which can be associated with GL, VK or even display
contexts.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/117}

Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / GPU Device},
\ref{sec:Device Types / GPU Device / Feature bits},
\ref{sec:Device Types / GPU Device / Device Operation / Device Operation: Request header},
\ref{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq},
and \ref{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq (3d)}.
 } \\
\hline
e0e8f9ac37c5 & 04 Oct 2021 & Junji Wei & { Reserve device id for RDMA device


Use device ID 42

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/116}

Signed-off-by: Junji Wei <weijunji@bytedance.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types}.
 } \\
\hline
f5a8d38acbd0 & 04 Oct 2021 & Max Gurtovoy & { Fix copy/paste bug in PCI transport paragraph


Refer to "Shared memory capability" and not to "Device-specific
configuration".

Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Shared memory capability}.
 } \\
\hline
bcf4bddb256e & 07 Oct 2021 & Jean-Philippe Brucker & { content: Remove duplicate paragraph


It looks like commit 356aeeb40d7a ("content: add vendor specific cfg
type") had a merge issue. It includes the device normative paragraph for
Shared memory capability, which was already added right above it by
commit 855ad7af2bd6 ("shared memory: Define PCI capability").

The two paragraphs differ, and the first paragraph is correct. It refers
to struct virtio_pci_cap64 which embeds struct virtio_pci_cap:

  struct virtio_pci_cap64 .

    struct virtio_pci_cap .

      ...
      le32 offset;
      le32 length;
    \} cap;
    u32 offset_hi;
    u32 length_hi;
  .


Merge the two paragraph while keeping the best of both. Drop the spaces
after \textbackslash field to stay consistent with the rest of the document.

Acked-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Shared memory capability}.
 } \\
\hline
591eb4c2f76e & 07 Oct 2021 & Cornelia Huck & { PCI: fix level for vendor data capability


The normative statements for the vendor data capability need
to be at paragraph level insted of subsection level.

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Vendor data capability}.
 } \\
\hline
2f4a36d5e36d & 14 Oct 2021 & Enrico Granata & { Provide detailed specification of virtio-blk lifetime metrics


In the course of review, some concerns were surfaced about the
original virtio-blk lifetime proposal, as it depends on the eMMC
spec which is not open

Add a more detailed description of the meaning of the fields
added by that proposal to the virtio-blk specification, as to
make it feasible to understand and implement the new lifetime
metrics feature without needing to refer to JEDEC's specification

This patch does not change the meaning of those fields nor add
any new fields, but it is intended to provide an open and more
clear description of the meaning associated with those fields.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/106}

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Enrico Granata <egranata@google.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Block Device / Device Operation}.
 } \\
\hline
fc387ffae917 & 15 Oct 2021 & Pankaj Gupta & { virtio-pmem: PMEM device spec


Posting virtio specification for virtio pmem device. Virtio pmem is a
paravirtualized device which allows the guest to bypass page cache.
Virtio pmem kernel driver is merged in Upstream Kernel 5.3. Also, Qemu
device is merged in Qemu 4.1.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/78}

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>

[CH: editorial update to fix conformance section]

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / PMEM Device}.
 } \\
\hline
b5115a8fc8ed & 15 Oct 2021 & David Hildenbrand & { virtio-mem: simplify statements that express unexpected behavior on memory access


Some statements express that the device MAY allow access to memory inside
unplugged memory blocks, although it's really just unexpected behavior and
conforming drivers MUST NOT perform such access.

Clarify that, and move the special CPU vs. DMA handling for some
unplugged memory blocks to the driver section instead.

While at it, start rephrasing our statements to clarify and prepare for
further changes.

Signed-off-by: David Hildenbrand <david@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Memory Device / Device Operation}.
 } \\
\hline
708ef827b092 & 15 Oct 2021 & David Hildenbrand & { virtio-mem: rephrase remaining memory access statements


Let's rephrase the remaining statements regarding memory access to unify
and prepare for further changes.

Signed-off-by: David Hildenbrand <david@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Memory Device / Device Operation}.
 } \\
\hline
f579906e7364 & 15 Oct 2021 & David Hildenbrand & { virtio-mem: document basic memory access to plugged memory blocks


Let's cleanly document that the driver just has to allow for access to
plugged memory blocks.

Signed-off-by: David Hildenbrand <david@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Memory Device / Device Operation}.
 } \\
\hline
5b6a9d2a1d43 & 15 Oct 2021 & David Hildenbrand & { virtio-mem: introduce VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE


Until now, we allowed a driver to read unplugged memory within the
usable device-managed region: this simplified bring-up of virtio-mem in
Linux quite a bit, especially when it came to physical memory dumping.

When the device is using a memory backend that supports a shared
zeropage, such as virtio-mem in QEMU under Linux on anonymous memory, the
old behavior could be realized easily.

However, when using other memory backends (such as hugetlbfs or shmem)
or architectures, such as s390x, where a shared zeropage either does not
exist or cannot be used, letting the driver read unplugged memory can
result in undesired memory consumption in the hypervisor. The device
wants to make sure that the guest is aware and will not read unplugged
memory, not even in corner cases.

In the meantime, the Linux implementation matured such that it will no
longer access unplugged memory, for example, during kdump, when reading
/proc/kcore, or via (now removed) /dev/kmem.

Similar to VIRTIO_F_ACCESS_PLATFORM, this change will be disruptive and
require driver adaptions -- even if it's just accepting the new feature.
Devices are expected to only set the bit when really required, to keep
existing setups working.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/118}

Signed-off-by: David Hildenbrand <david@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Memory Device / Feature bits},
\ref{Device Types / Memory Device / Device Initialization},
and \ref{sec:Device Types / Memory Device / Device Operation}.
 } \\
\hline
26947c3e7b05 & 15 Oct 2021 & David Hildenbrand & { virtio-mem: describe interaction with memory properties


Let's describe how we expect the interaction with memory properties that
might be available on a specific platform for ordinary system RAM.

This is primarily a preparation for s390x support, which provides
storage keys and may provide storage attributes, depending on the system
configuration.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/118}

Signed-off-by: David Hildenbrand <david@redhat.com>

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Memory Device},
\ref{sec:Device Types / Memory Device / Feature bits},
\ref{Device Types / Memory Device / Device Initialization},
and \ref{sec:Device Types / Memory Device / Device Operation}.
 } \\
\hline
ca1463daea5d & 03 Nov 2021 & Viresh Kumar & { virtio: i2c: No need to have separate read-write buffers


The virtio I2C protocol allows to contain multiple read-write requests
in a single I2C transaction using the VIRTIO_I2C_FLAGS_FAIL_NEXT flag,
where each request contains a header, buffer and status.

There is no need to pass both read and write buffers in a single
request, as we have a better way of combining requests into a single I2C
transaction. Moreover, this also limits the transactions to two buffers,
one for read operation and one for write. By using
VIRTIO_I2C_FLAGS_FAIL_NEXT, we don't have any such limits.

Remove support for multiple buffers within a single request.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/112}

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Reviewed-by: Jie Deng <jie.deng@intel.com>

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / I2C Adapter Device / Device Operation: Request Queue},
and \ref{sec:Device Types / I2C Adapter Device / Device Operation: Operation Status}.
 } \\
\hline
69d399bd3f19 & 03 Nov 2021 & Viresh Kumar & { virtio: i2c: Allow zero-length transactions


The I2C protocol allows zero-length requests with no data, like the
SMBus Quick command, where the command is inferred based on the
read/write flag itself.

In order to allow such a request, allocate another bit,
VIRTIO_I2C_FLAGS_M_RD(1), in the flags to pass the request type, as read
or write. This was earlier done using the read/write permission to the
buffer itself.

Add a new feature flag for zero length requests and make it mandatory
for it to be implemented, so we don't need to drag the old
implementation around.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/112}

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Reviewed-by: Jie Deng <jie.deng@intel.com>

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Device Types / I2C Adapter Device / Feature bits},
\ref{sec:Device Types / I2C Adapter Device / Device Operation: Request Queue},
and \ref{sec:Device Types / I2C Adapter Device / Device Operation: Operation Status}.
 } \\
\hline
ca3252712d98 & 03 Nov 2021 & Viresh Kumar & { virtio-gpio: Add support for interrupts


This patch adds support for interrupts to the virtio-gpio specification.
This uses the feature bit 0 for the same.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/114}

Cc: Marc Zyngier <maz@kernel.org>

Cc: Thomas Gleixner <tglx@linutronix.de>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

See \ref{sec:Device Types / GPIO Device / Virtqueues},
\ref{sec:Device Types / GPIO Device / Feature bits},
\ref{sec:Device Types / GPIO Device / Device configuration layout},
and \ref{sec:Device Types / GPIO Device / requestq Operation}.
 } \\
\hline
48340e86b087 & 29 Nov 2021 & Halil Pasic & { split-ring: clarify the field len in the used ring


The current description is misleading: "the descriptor chain which was
used" generally includes both the descriptors that map the device read
only, and descriptors that  map the device write only portions of the
buffer described by the descriptor chain. The argument that "used" means
"written to" does not stand because one has to "use" the descriptor
chain even when the whole buffer is device read only.

One can argue, that the most straightforward way to interpret the phrase
"total length of that descriptor chain" (without context) like the
length of the  list is usually defined: i.e. like the number of
descriptors that constitute the chain. This is clearly not what we want
here. Another intuitive way to interpret "total length of that
descriptor chain" is size of the buffer mapped by the descriptor chain.
This is not what we want either. In fact such wrongful interpretations
have caused bugs in the wild.

On the other hand, the text below the listing that gets modified here
clearly describes the semantics of \textbackslash field\{len\}. So let us replace
the ambiguous explanation in the listing, with a hopefully non-ambiguous
one.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>

[CH: fixed up commit message typo and tabs-vs-spaces]

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Used Ring}.
 } \\
\hline
795391311bb1 & 30 Nov 2021 & Taylor Stark & { virtio-pmem: Support describing pmem as shared memory region


Update the virtio-pmem spec to add support for describing the pmem region as a
shared memory window. This is required to support virtio-pmem in Hyper-V, since
Hyper-V only allows PCI devices to operate on memory ranges defined via BARs.
When using the virtio PCI transport, shared memory regions are described via
PCI BARs.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/121}

Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>

Signed-off-by: Taylor Stark <tstark@microsoft.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / PMEM Device / Feature bits},
\ref{sec:Device Types / PMEM Device / Device configuration layout},
and \ref{sec:Device Types / PMEM Device / Device Initialization}.
 } \\
\hline
ec3997b8a402 & 30 Nov 2021 & Cornelia Huck & { pmem: correct wording


s/guest absolute/physical/

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / PMEM Device / Device Initialization}.
 } \\
\hline
d6645979da9b & 07 Dec 2021 & Cornelia Huck & { ccw: clarify device reset


Unlike other transports, a reset triggered by the driver is actually
complete once the command has been completed. Make this behaviour
and the requirements more explicit.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/123}

Reviewed-by: Jason Wang <jasowang@redhat.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}.
 } \\
\hline
41644c17c971 & 09 Dec 2021 & Jean-Philippe Brucker & { virtio-iommu: Rework the bypass feature


The VIRTIO_IOMMU_F_BYPASS feature is awkward to use and incomplete.
Although it is implemented by QEMU, it is not supported by any driver as
far as I know. Replace it with a new VIRTIO_IOMMU_F_BYPASS_CONFIG
feature.

Two features are missing from virtio-iommu:

* The ability for an hypervisor to start the device in bypass mode. The
  wording for VIRTIO_IOMMU_F_BYPASS is not clear enough to allow it at
  the moment, because it only specifies the behavior after feature
  negotiation.

* The ability for a guest to set individual endpoints in bypass mode
  when bypass is globally disabled. An OS should have the ability to
  allow only endpoints it trusts to bypass the IOMMU, while keeping DMA
  disabled for endpoints it isn't even aware of. At the moment this can
  only be emulated by creating identity mappings.

The VIRTIO_IOMMU_F_BYPASS_CONFIG feature adds a 'bypass' config field
that allows to enable and disable bypass globally. It also adds a new
flag for the ATTACH request.

* The hypervisor can start the VM with bypass enabled or, if it knows
  that the software stack supports it, disabled. The 'bypass' config
  fields is initialized to 0 or 1. It is sticky and isn't affected by
  device reset.

* Generally the firmware won't have an IOMMU driver and will need to be
  started in bypass mode, so the bootloader and kernel can be loaded
  from storage endpoint.

  For more security, the firmware could implement a minimal virtio-iommu
  driver that reuses existing virtio support and only touches the config
  space. It could enable PCI bus mastering in bridges only for the
  endpoints that need it, enable global IOMMU bypass by flipping a bit,
  then tear everything down before handing control over to the OS. This
  prevents vulnerability windows where a malicious endpoint reprograms
  the IOMMU while the OS is configuring it [1].

  The isolation provided by vIOMMUs has mainly been used for securely
  assigning endpoints to untrusted applications so far, while kernel DMA
  bypasses the IOMMU. But we can expect boot security to become as
  important in virtualization as it presently is on bare-metal systems,
  where some devices are untrusted and must never be able to access
  memory that wasn't assigned to them.

* The OS can enable and disable bypass globally. It can then enable
  bypass for individual endpoints by attaching them to bypass domains,
  using the new VIRTIO_IOMMU_ATTACH_F_BYPASS flag. It can disable bypass
  by attaching them to normal domains.

[1] IOMMU protection against I/O attacks: a vulnerability and a proof of concept
    Morgan, B., Alata, É., Nicomette, V. et al.
    \url{https://link.springer.com/article/10.1186/s13173-017-0066-7}

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/119}

Reviewed-by: Eric Auger <eric.auger@redhat.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / IOMMU Device / Feature bits},
\ref{sec:Device Types / IOMMU Device / Device configuration layout},
\ref{sec:Device Types / IOMMU Device / Device initialization},
and \ref{sec:Device Types / IOMMU Device / Device operations}.
 } \\
\hline
ed9152310708 & 21 Dec 2021 & Yadong Qi & { virtio-blk: add secure erase feature to specification


There are user requests to use the Linux BLKSECDISCARD ioctl on
virtio-blk device. A secure discard is the same as a regular discard
except that all copies of the discarded blocks that were possibly
created by garbage collection must also be erased. This requires
support from the device. And "secure erase" is more commonly used
in industry to name this feature. Hence in this proposal, extend
virtio-blk protocol to support secure erase command.

Introduced new feature flag and command type:
    VIRTIO_BLK_F_SECURE_ERASE
    VIRTIO_BLK_T_SECURE_ERASE

This feature is a passthrough feature on backend because it is hard
to emulate a secure erase. So virtio-blk will report this feature
to guest OS if backend device support such kind of feature. And
when guest OS issues a secure erase command, backend driver will
passthrough the command to host device blocks.

Introduced new fields in virtio_blk_config for secure erase commands:
struct virtio_blk_config .

    ...
    max_secure_erase_sectors;
    max_secure_erase_seg;
    secure_erase_sector_alignment;
\};

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/125}

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Yadong Qi <yadong.qi@intel.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Block Device / Feature bits},
\ref{sec:Device Types / Block Device / Device configuration layout},
\ref{sec:Device Types / Block Device / Device Initialization},
and \ref{sec:Device Types / Block Device / Device Operation}.
 } \\
\hline
3b5378d70a42 & 21 Dec 2021 & Xuan Zhuo & { virtio: introduce virtqueue reset as basic facility


This patch allows the driver to reset a queue individually.

This is very common on general network equipment. By disabling a queue,
you can quickly reclaim the buffer currently on the queue. If necessary,
we can reinitialize the queue separately.

For example, when virtio-net implements support for AF_XDP, we need to
disable a queue to release all the original buffers when AF_XDP setup.
And quickly release all the AF_XDP buffers that have been placed in the
queue when AF_XDP exits.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/124}

Reviewed-by: Jason Wang <jasowang@redhat.com>

Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues},
and \ref{sec:Reserved Feature Bits}.
 } \\
\hline
12998e738621 & 21 Dec 2021 & Xuan Zhuo & { virtio: pci support virtqueue reset


PCI support virtqueue reset.

virtio_pci_common_cfg add "queue_reset" to support virtqueue reset.
The driver uses this to selectively reset the queue.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/124}

Reviewed-by: Jason Wang <jasowang@redhat.com>

Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Common configuration structure layout}.
 } \\
\hline
a4ce81a83780 & 21 Dec 2021 & Xuan Zhuo & { virtio: mmio support virtqueue reset


mmio support virtqueue reset.

MMIO Device Register Layout "QueueReady" to support virtqueue reset.
The driver uses this to selectively reset the queue.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/124}

Reviewed-by: Jason Wang <jasowang@redhat.com>

Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over MMIO / MMIO Device Register Layout}.
 } \\
\hline
f65613a48826 & 11 Jan 2022 & Max Gurtovoy & { Fix reserved Feature bits numbering


This should have been updated during VIRTIO_F_NOTIFICATION_DATA,
VIRTIO_F_NOTIF_CONFIG_DATA and VIRTIO_F_RING_RESET standartization.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/128}

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Basic Facilities of a Virtio Device / Feature Bits}.
 } \\
\hline
5e1c3fa81e29 & 21 Jan 2022 & Arseny Krasnov & { virtio-vsock: use C style defines for constants


This:
1) Replaces enums with C style "defines", because
   use of enums is not documented, while "defines"
   are widely used in spec.
2) Adds defines for some constants.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Arseny Krasnov <arseny.krasnov@kaspersky.com>

Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Socket Device / Device Operation}.
 } \\
\hline
1a90fc6e4228 & 21 Jan 2022 & Stefano Garzarella & { virtio-vsock: add VIRTIO_VSOCK_F_STREAM feature bit


Initially vsock devices only supported stream sockets, but now
we are adding support for new types (i.e. SEQPACKET, DGRAM).

Since some devices may not want to support stream sockets, we add
a feature bit for this type.

For backward compatibility, if no feature bit is set, only stream
socket type is supported.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Socket Device / Feature bits}.
 } \\
\hline
d6d9c734b42e & 21 Jan 2022 & Arseny Krasnov & { virtio-vsock: SOCK_SEQPACKET description


This adds description of SOCK_SEQPACKET socket type
support for virtio-vsock.

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/132}

Signed-off-by: Arseny Krasnov <arseny.krasnov@kaspersky.com>

[reworked "Message and record boundaries" paragraph]

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / Socket Device / Feature bits},
and \ref{sec:Device Types / Socket Device / Device Operation}.
 } \\
\hline
88895f56e642 & 24 Jan 2022 & Cornelia Huck & { Reserve more feature bits for device type usage


Feature bits 41 and above are noted as being reserved for future
extensions. However, the net device has been using bits in that space
for some time now, as it already used up the device type specific
range up to 23.

To avoid problems in the future, let's designate bits 50 to 127 to
device type specific usage (which accommodates current usage by the
net driver, and gives breathing room for future type specific bits),
and declare bits 41 to 49 and bits 128 and above to be reserved for
future extensions (which gives us some time before bit numbers move
beyond 63, which would need some changes in existing device and driver
implementations.)

Reported-by: Max Gurtovoy <mgurtovoy@nvidia.com>

Fixes: \url{https://github.com/oasis-tcs/virtio-spec/issues/131}

Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Basic Facilities of a Virtio Device / Feature Bits}.
 } \\
\hline
6708e0fc2f7d & 07 Apr 2022 & Michael S. Tsirkin & { virtio-gpio: offered -> negotiated


virtqueues are only discovered after FEATURES_OK.
As such it makes no sense to talk about virtqueues being affected by
features which are offered but not negotiated, and doing so will confuse
the reader.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Device Types / GPIO Device / Virtqueues}.
 } \\
\hline
a214ffb64f45 & 11 Apr 2022 & Cornelia Huck & { introduction: add more section labels


In order to be able to refer to changes in sections.

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Structure Specifications},
and \ref{sec:Constant Specifications}.
 } \\
\hline
79f705b96040 & 11 Apr 2022 & Cornelia Huck & { conformance: hook up GPU device normative statements


These statements already exist, but were not linked in the conformance section.

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Conformance / Conformance Targets}.
 } \\
\hline
26f15550226b & 19 Apr 2022 & Michael S. Tsirkin & { packed-ring: fix some typos


The VIRTQ_DESC_F_INDIRECT flag is misnamed in a couple of places.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{drivernormative:Basic Facilities of a Virtio Device / Packed Virtqueues / The Virtqueue Descriptor Table / Indirect Descriptors}.
 } \\
\hline
b13f67fca90e & 20 Apr 2022 & Michael S. Tsirkin & { packed-ring.tex: link conformance statements


Link conformance statements into conformance chapter.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Conformance / Conformance Targets}.
 } \\
\hline
3a7f07897958 & 20 Apr 2022 & Michael S. Tsirkin & { content.tex: drop space after \textbackslash field


Always use \textbackslash field\{foo\} not \textbackslash field \{foo\}, the latter confuses
latexdiff.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Signed-off-by: Cornelia Huck <cohuck@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
 } \\
\hline
c5fd7eda1203 & 29 Apr 2022 & Parav Pandit & { virtio: Improve queue_reset polarity to match to default reset state
    
    Currently when driver initiates a queue reset, device is expected
    to communicate reset status to the driver by changing the value of the
    queue_reset register twice. First to return value other than 1 when
    reset is ongoing, later to return 1 when queue reset is completed.
    
    However initially during the device reset time the queue reset value
    is zero. queue_reset changes the value of the register to a different
    value on reset completion. Yet another time queue_reset value is
    expected to change when queue_select is reprogrammed.
    
    Instead, it is better and efficient to maintain the same VQ state
    on the device when queue reset is completed.
    
    new proposed flow:

    q_enable, q_reset

    A) 0, 0 -> default, device init time

    B) 1, 0 -> driver has enabled vq

    C) 1, 1 -> driver started q reset

    D) 1, 1 -> q_reset stays 1 until device is busy resetting vq
    (device communicates that its working on resetting VQ,
	consistent with \#C)

    E) 0, 0 -> q_reset by device is completed, q got disabled
    (consistent with device init time \#A)
    
    Hence, this patch proposes a simple change to have reset register
    polarity to be same as that of initial reset value.
    
    Fixes: https://github.com/oasis-tcs/virtio-spec/issues/139

    Fixes: 12998e738621 ("virtio: pci support virtqueue reset")

    Fixes: a4ce81a83780 ("virtio: mmio support virtqueue reset")

    Fixes: 3b5378d70a42 ("virtio: introduce virtqueue reset as basic facility")

    Reviewed-by: Jason Wang <jasowang@redhat.com>

    Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>

    Signed-off-by: Parav Pandit <parav@nvidia.com>

    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Common configuration structure layout}
and
\ref{sec:Virtio Transport Options / Virtio Over MMIO / MMIO Device Register Layout}.
 } \\
\hline
