From 0be6c18bce52e3b0bcfcf087a163b975bede8c23 Mon Sep 17 00:00:00 2001 From: mstsirkin Date: Tue, 23 Dec 2014 19:28:10 +0000 Subject: feedback: drop unused feedback files So that we don't need to remove them manually. Signed-off-by: Michael S. Tsirkin git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@465 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652 --- feedback/2.txt | 222 --------------------------------------------------------- 1 file changed, 222 deletions(-) delete mode 100644 feedback/2.txt (limited to 'feedback/2.txt') diff --git a/feedback/2.txt b/feedback/2.txt deleted file mode 100644 index e02264a..0000000 --- a/feedback/2.txt +++ /dev/null @@ -1,222 +0,0 @@ -Document: virtio-v1.0-csprd01 -Number: 2 -Date: Fri, 10 Jan 2014 13:49:49 +0100 -Link to Mail: https://lists.oasis-open.org/archives/virtio-comment/201401/msg00001.html -Commenter name: Thomas Huth -Decision: Agreed at meeting 2014-01-28. - -Here's my feedback for Virtio draft 01, chapter 4: - -Page 20 / PCI Device Layout: - -- "To configure the device, use I/O and/or memory regions and/or PCI -configuration - space of the PCI device." - => That sounds a little bit sparse/confusing. Maybe rather something like: - "To configure the device, it is possible to use the PCI configuration space - and/or to access the configuration data via an I/O and/or MMIO base-address - register." - -Page 21: - -- The "device_feature_select" and "driver_feature_select" paragraphs are -lacking - some punctuation marks inbetween. - -Page 23 / Virtio Device Configuration Layout Detection: - -- "This structure can optionally followed by extra data" - => "This structure can optionally be followed by extra data" - -Page 27 / MMIO Device Discovery: - -- The device tree snippet is obviously an example. That's ok, but I think the - spec should explicitely say so (and maybe add some generic words about the - required properties before the example, too). - -Chapter 4.3.2.*: - -- In this chapter, the C-structs are marked with "__attribute__ ((packed));" - which is just a GNU-C extension, as far as I know. In the other chapters, - the structs are not marked with this string. So for consistency, I'd remove - them here, too (and maybe state somewhere at the beginning of the spec - that structs are considered to be without compiler padding inbetween) - -Page 33: - -- Some typos: - neccessarily => necessarily - issueing => issuing - -Page 34 / Virtqueue Layout: - -- "... with padded added ..." - => "... with padding added ..." - -Page 34 / Handling Device Features: - -- The text says "Feature bits are in little-endian byte order", but the - "struct virtio_feature_desc" is described with "be32 features" ... - that's confusing -- are the feature bits now little or big endian? - -Page 36: - -- "Bit numbers start at the left" - => I'd make this sentence more explicit, e.g.: - "Bit numbers start at the left, i.e. the most significant bit in the - first byte is assigned the bit number 0." - -Page 36 / Notification via Adapter I/O Interrupts: - -- "The guest-provided summary indicator is also set." - => What value is set in the summary indicator byte? 0x01? 0x80? 0xff? - It maybe does not matter, since any non-zero value could be used, but - it might help to avoid confusion if you specify the exact value here. - -Page 37 / Early printk for Virtio Consoles - -- Is this early print really part of virtio-ccw? If yes, I think you - should also describe the register usage here. - -Proposal: - -Two patches: - -diff --git a/content.tex b/content.tex -index 803615d..4ebc4b1 100644 ---- a/content.tex -+++ b/content.tex -@@ -801,9 +801,10 @@ any Revision ID value. - - \subsection{PCI Device Layout}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout} - --To configure the device, --use I/O and/or memory regions and/or PCI configuration space of the PCI device. --These contain the virtio header registers, the notification register, the -+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 - Structure PCI Capabilities. - -@@ -847,8 +848,7 @@ Common configuration structure layout is documented below: - \begin{description} - \item[device_feature_select] - The driver uses this to select which Feature Bits the device_feature field shows. -- Value 0x0 selects Feature Bits 0 to 31 -- Value 0x1 selects Feature Bits 32 to 63 -+ Value 0x0 selects Feature Bits 0 to 31, 0x1 selects Feature Bits 32 to 63. - The device MUST present 0 on device_feature for any other value. - - \item[device_feature] -@@ -857,8 +857,7 @@ Common configuration structure layout is documented below: - - \item[driver_feature_select] - The driver uses this to select which Feature Bits the driver_feature field shows. -- Value 0x0 selects Feature Bits 0 to 31 -- Value 0x1 selects Feature Bits 32 to 63 -+ Value 0x0 selects Feature Bits 0 to 31, 0x1 selects Feature Bits 32 to 63. - When set to any other value, reads from driver_feature - return 0, writing 0 into driver_feature has no effect. The driver - MUST not write any other value into driver_feature (a corollary of -@@ -899,7 +898,7 @@ Common configuration structure layout is documented below: - - \item[queue_enable] - The driver uses this to selectively prevent the device from executing requests from this virtqueue. -- 1 - enabled; 0 - disabled -+ 1 - enabled; 0 - disabled. - - The driver MUST configure the other virtqueue fields before enabling - the virtqueue. -@@ -1043,7 +1042,7 @@ read-only: - }; - \end{lstlisting} - --This structure can optionally followed by extra data, depending on -+This structure can optionally be followed by extra data, depending on - other fields, as documented below. - - Note that future versions of this specification will likely -@@ -1369,10 +1368,13 @@ following sections. - - \subsection{MMIO Device Discovery}\label{sec:Virtio Transport Options / Virtio Over MMIO / MMIO Device Discovery} - --Unlike PCI, MMIO provides no generic device discovery. For --systems using Flattened Device Trees the suggested format is: -+Unlike PCI, MMIO provides no generic device discovery. For each -+device, the guest OS will need to know the location of the registers -+and interrupt(s) used. The suggested binding for systems using -+flattened device trees is shown in this example: - - \begin{lstlisting} -+ // EXAMPLE: virtio_block device taking 256 bytes at 0x1e000, interrupt 42. - virtio_block@1e000 { - compatible = "virtio,mmio"; - reg = <0x1e000 0x100>; -@@ -1941,7 +1943,7 @@ revision & length & data & remarks \\ - \hline - \end{tabular} - --Note that a change in the virtio standard does not neccessarily -+Note that a change in the virtio standard does not necessarily - correspond to a change in the virtio-ccw revision. - - A device MUST post a unit check with command reject for any revision -@@ -2037,7 +2039,7 @@ and align the alignment. - - \subsubsection{Virtqueue Layout}\label{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Virtqueue Layout} - --The virtqueue is physically contiguous, with padded added to make the -+The virtqueue is physically contiguous, with padding added to make the - used ring meet the align value: - - \begin{tabular}{|l|l|l|} - -Subject: [PATCH 1/1] virtio-ccw: clarifications - -- further qualify bit numbering -- specify summary indicator contents -- drop early printk spec; it is only a hack that was never used upstream - -Reported-by: Thomas Huth -Signed-off-by: Cornelia Huck ---- - content.tex | 10 +++------- - 1 file changed, 3 insertions(+), 7 deletions(-) - -diff --git a/content.tex b/content.tex -index 803615d..0a94c07 100644 ---- a/content.tex -+++ b/content.tex -@@ -2174,7 +2174,8 @@ summary_indicator contains the guest address of the 8 bit summary - indicator. - indicator contains the guest address of an area wherin the indicators - for the devices are contained, starting at bit_nr, one bit per --virtqueue of the device. Bit numbers start at the left. -+virtqueue of the device. Bit numbers start at the left, i.e. the most -+significant bit in the first byte is assigned the bit number 0. - isc contains the I/O interruption subclass to be used for the adapter - I/O interrupt. It may be different from the isc used by the proxy - virtio-ccw device's subchannel. -@@ -2224,7 +2225,7 @@ host->guest notification about virtqueue activity. - - For notifying the driver of virtqueue buffers, the device sets the - bit in the guest-provided indicator area at the corresponding offset. --The guest-provided summary indicator is also set. An adapter I/O -+The guest-provided summary indicator is set to 0x01. An adapter I/O - interrupt for the corresponding interruption subclass is generated. - The device SHOULD only generate an adapter I/O interrupt if the - summary indicator had not been set prior to notification. The driver -@@ -2273,11 +2274,6 @@ should be passed in GPR4 for the next notification: - info->cookie); - \end{lstlisting} - --\subsubsection{Early printk for Virtio Consoles}\label{sec:Virtio Transport Options / Virtio over channel I/O / Device Operation / Early printk for Virtio Consoles} -- --For the early printk mechanism, diagnose 0x500 with subcode 0 is --used. -- - \subsubsection{Resetting Devices}\label{sec:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices} - - In order to reset a device, a driver sends the -- cgit v1.2.3