[PATCH] feedback: s/virtio header/virtio common configuration/

While most places now sat virtio common configuration structure, some places still use the term virtio header. Since it's not necessarily before the common configuration anymore, rename it to virtio common configuration structure for consistency.
Cc: Arun Subbarao <> Signed-off-by: Michael S. Tsirkin <> ---  content.tex
18 +++++++

-----------

1 file changed, 7 insertions(+), 11 deletions(-)  diff --git a/content.tex b/content.tex index 85452e8..b00ea09 100644 --- a/content.tex +++ b/content.tex @@ -820,18 +820,14 @@ any Revision ID value.  The device is configured via I/O and/or memory regions (though see  VIRTIO_PCI_CAP_PCI_CFG for access via the PCI configuration space).
-These regions contain the virtio header registers, the notification register, the -ISR status register and device specific registers, as specified by Virtio +These regions contain the virtio common configuration structure registers, the notification register, the +ISR status register and device specific configuration registers, as specified by Virtio  Structure PCI Capabilities.
There may be different widths of accesses to the I/O region; the  “natural” access method for each field must be  used (i.e. 32-bit accesses for 32-bit fields, etc).
-PCI Device Configuration Layout includes the common configuration, -ISR, notification and device specific configuration -structures. -  All multi-byte fields are little-endian.
subsubsection{Common configuration structure layout}label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Common configuration structure layout} @@ -954,18 +950,18 @@ registers in a legacy configuration structure in BAR0 in the first I/O  region of the PCI device, as documented below.
There may be different widths of accesses to the I/O region; the -“natural” access method for each field in the virtio header must be +“natural” access method for each field in the virtio common configuration structure must be  used (i.e. 32-bit accesses for 32-bit fields, etc), but
when accessed through the legacy interface the  device-specific region can be accessed using any width accesses, and  should obtain the same results.
-Note that this is possible because while the virtio header is PCI +Note that this is possible because while the virtio common configuration structure is PCI  (i.e. little) endian, when using the legacy interface the device-specific  region is encoded in the native endian of the guest (where such distinction is  applicable).
-When used through the legacy interface, the virtio header looks as follows: +When used through the legacy interface, the virtio common configuration structure looks as follows:
egin{tabularx}{	extwidth}{  X  X X X X X X X X  }  hline @@ -993,7 +989,7 @@ Purpose (MSI-X) & Configuration Vector  & Queue Vector \  end{tabular}
Note: When MSI-X capability is enabled, device specific configuration starts at -byte offset 24 in virtio header structure. When MSI-X capability is not +byte offset 24 in virtio common configuration structure structure. When MSI-X capability is not  enabled, device specific configuration starts at byte offset 20 in virtio  header.  ie. once you enable MSI-X on the device, the other fields move.  If you turn it off again, they move back! @@ -1352,7 +1348,7 @@ The driver interrupt handler should:  subsubsection{Notification of Device Configuration Changes}label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Notification of Device Configuration Changes}
Some virtio PCI devices can change the device configuration -state, as reflected in the virtio header in the PCI configuration +state, as reflected in the virtio common configuration structure in the PCI configuration  space. In this case:
egin{itemize}

--
MST