Re: [virtio-dev] [PATCH] 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: https://github.com/oasis-tcs/virtio-spec/issues/55
> Signed-off-by: Michael S. Tsirkin
Reviewed-by: Pankaj Gupta
> ---
> content.tex | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/content.tex b/content.tex
> index 678afbe..72e832e 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -4721,7 +4721,7 @@ \subsection{Device Operation}\label{sec:Device Types /
> Entropy Device / Device O
>
> \drivernormative{\subsubsection}{Device Operation}{Device Types / Entropy
> Device / Device Operation}
>
> -The driver MUST NOT place driver-readable buffers into the queue.
> +The driver MUST NOT place device-readable buffers into the queue.
>
> The driver MUST examine the length written by the device to determine
> how many random bytes were received.
> --
> MST
>
>
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
>
>
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] [PATCH RESEND v4 1/1] Add virtio-iommu device specification
On 20.11.19 16:19, Jean-Philippe Brucker wrote:
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: https://github.com/oasis-tcs/virtio-spec/issues/37
Signed-off-by: Jean-Philippe Brucker
...
+
+\subsubsection{Fault reporting}\label{sev:Device Types / IOMMU Device / Device
operations / Fault reporting}
+
+The device can report translation faults and other significant
+asynchronous events on the event virtqueue. The driver initially populates
+the queue with device-writeable buffers. When the device needs to report
+an event, it fills a buffer and notifies the driver. The driver consumes
+the report and adds a new buffer to the virtqueue.
+
+If no buffer is available, the device can either wait for one to be
+consumed, or drop the event.
+
+\begin{lstlisting}
+struct virtio_iommu_fault {
+ u8reason;
+ u8reserved[3];
+ le32 flags;
+ le32 endpoint;
+ le32 reserved1;
+ le64 address;
+};
+
+#define VIRTIO_IOMMU_FAULT_F_READ (1 << 0)
+#define VIRTIO_IOMMU_FAULT_F_WRITE(1 << 1)
+#define VIRTIO_IOMMU_FAULT_F_ADDRESS (1 << 8)
+\end{lstlisting}
+
+\begin{description}
+ \item[\field{reason}] The reason for this report. It may have the
+following values:
+\begin{description}
+ \item[VIRTIO_IOMMU_FAULT_R_UNKNOWN (0)] An internal error happened, or
+an error that cannot be described with the following reasons.
+ \item[VIRTIO_IOMMU_FAULT_R_DOMAIN (1)] The endpoint attempted to
+access \field{address} without being attached to a domain.
+ \item[VIRTIO_IOMMU_FAULT_R_MAPPING (2)] The endpoint attempted to
+access \field{address}, which wasn't mapped in the domain or
+didn't have the correct protection flags.
+\end{description}
+ \item[\field{flags}] Information about the fault context.
+ \item[\field{endpoint}] The endpoint causing the fault.
+ \item[\field{reserved} and \field{reserved1}] Should be zero.
+ \item[\field{address}] If VIRTIO_IOMMU_FAULT_F_ADDRESS is set, the
+address causing the fault.
+\end{description}
+
+When the fault is reported by a physical IOMMU, the fault reasons may not
+match exactly the reason of the original fault report. The device does its
+best to find the closest match.
+
+If the device encounters an internal error that wasn't caused by a
+specific endpoint, it is unlikely that the driver would be able to do
+anything else than print the fault and stop using the device, so reporting
+the fault on the event queue isn't useful. In that case, we recommend
+using the DEVICE_NEEDS_RESET status bit.
What's the impact of a fault on the device(s) under the IOMMU regime?
Can they recover? Or will they get DEVICE_NEEDS_RESET as well? With PCI
device behind real IOMMUs, it's normal that they need a reset after
having caused a fault. I'm not sure if this is described in the related
specs for them, but it should be clarify for the virtual IOMMU. But this
can be done on top, IMHO.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [virtio] [PATCH] pci: strengthen requirement of the correct subsystem id
On 28.10.19 17:12, Michael S. Tsirkin wrote:
If a hardware implementation of virtio does not have
the correct subsystem id, then drivers can't report
ir properly, or detect and work around bugs.
s/ir/it.
Jan
Change the requirement from MAY to SHOULD.
We can't make it a MUST since we did not require this
historically.
Signed-off-by: Michael S. Tsirkin
---
content.tex | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content.tex b/content.tex
index 4bcb728..8f1518c 100644
--- a/content.tex
+++ b/content.tex
@@ -562,7 +562,7 @@ \subsection{PCI Device Discovery}\label{sec:Virtio
Transport Options / Virtio Ov
For example, the network card device with the Virtio Device ID 1
has the PCI Device ID 0x1041 or the Transitional PCI Device ID 0x1000.
-The PCI Subsystem Vendor ID and the PCI Subsystem Device ID MAY reflect
+The PCI Subsystem Vendor ID and the PCI Subsystem Device ID SHOULD reflect
the PCI Vendor and Device ID of the environment (for informational purposes
by the driver).
Non-transitional devices SHOULD have a PCI Device ID in the range
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] [PATCH] 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: https://github.com/oasis-tcs/virtio-spec/issues/55
Signed-off-by: Michael S. Tsirkin
---
content.tex | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content.tex b/content.tex
index 678afbe..72e832e 100644
--- a/content.tex
+++ b/content.tex
@@ -4721,7 +4721,7 @@ \subsection{Device Operation}\label{sec:Device Types /
Entropy Device / Device O
\drivernormative{\subsubsection}{Device Operation}{Device Types / Entropy
Device / Device Operation}
-The driver MUST NOT place driver-readable buffers into the queue.
+The driver MUST NOT place device-readable buffers into the queue.
The driver MUST examine the length written by the device to determine
how many random bytes were received.
--
MST
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH] content: add vendor specific cfg type
On Mon, Oct 28, 2019 at 06:55:42AM -0400, Michael S. Tsirkin wrote:
> 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.
>
> Signed-off-by: Michael S. Tsirkin
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/62
> ---
> content.tex | 80 +
> 1 file changed, 80 insertions(+)
>
> diff --git a/content.tex b/content.tex
> index b1ea9b9..8a79b03 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -691,6 +691,8 @@ \subsection{Virtio Structure PCI
> Capabilities}\label{sec:Virtio Transport Option
> #define VIRTIO_PCI_CAP_PCI_CFG 5
> /* Shared memory region */
> #define VIRTIO_PCI_CAP_SHARED_MEMORY_CFG 8
> +/* Vendor-specific data */
> +#define VIRTIO_PCI_CAP_VENDOR_CFG9
> \end{lstlisting}
>
> Any other value is reserved for future use.
> @@ -1099,6 +1101,84 @@ \subsubsection{Shared memory
> capability}\label{sec:Virtio Transport Options / Vi
>
> The \field{cap.id} MUST be unique for any one device instance.
>
> +\devicenormative{\paragraph}{Device-specific configuration}{Virtio Transport
> Options / Virtio Over PCI Bus / PCI Device Layout / Shared memory capability}
> +
> +The region defined by the combination of the \field {cap.offset},
> +\field {cap.offset_hi}, and \field {cap.length}, \field
> +{cap.length_hi} fields MUST be contained within the declared bar.
> +
> +The \field{cap.id} MUST be unique for any one device instance.
> +
> +\subsubsection{Vendor data capability}\label{sec:Virtio
> +Transport Options / Virtio Over PCI Bus / PCI Device Layout /
> +Vendor data capability}
> +
> +The optional Vendor data capability allows the device to present
> +vendor-specific data to the driver, without
> +conflicts, for debugging and/or reporting purposes,
> +and without conflicting with standard functionality.
> +
> +This capability augments but does not replace the standard
> +subsystem ID and subsystem vendor ID fields
> +(offsets 0x2C and 0x2E in the PCI configuration space header)
> +as specified by \hyperref[intro:PCI]{[PCI]}.
> +
> +Vendor data capability is enumerated on the PCI transport
> +as a VIRTIO_PCI_CAP_VENDOR_CFG capability.
> +
> +The capability has the following structure:
> +\begin{lstlisting}
> +struct virtio_pci_vndr_data {
> +u8 cap_vndr;/* Generic PCI field: PCI_CAP_ID_VNDR */
> +u8 cap_next;/* Generic PCI field: next ptr. */
> +u8 cap_len; /* Generic PCI field: capability length */
> +u8 cfg_type;/* Identifies the structure. */
> +u16 vendor_id; /* Identifies the vendor-specific format. */
> + /* For Vendor Definition */
> + /* Pads structure to a multiple of 4 bytes */
> + /* Reads must not have side effects */
> +};
> +\end{lstlisting}
> +
> +Where \field{vendor_id} identifies the PCI-SIG assigned Vendor ID
> +as specified by \hyperref[intro:PCI]{[PCI]}.
> +
> +Note that the capability size is required to be a multiple of 4.
> +
> +To make it safe for a generic driver to access the capability,
> +reads from this capability MUST NOT have any side effects.
> +
> +\devicenormative{\subsection}{Vendor data capability}{Virtio
> +Transport Options / Virtio Over PCI Bus / PCI Device Layout /
> +Vendor data capability}
> +
> +The device SHOULD present the PCI subsystem vendor ID matching
> +the device vendor, at offset 0x2C in its PCI configuration space
> +header.
> +
> +Devices CAN present \field{vendor_id} that does not match
> +either the PCI Vendor ID or the PCI Subsystem Vendor ID.
> +
> +Devices CAN present multiple Vendor data capabilities with
> +either different or identical \field{vendor_id} values.
> +
> +The value \field{vendor_id} MUST NOT equal 0x1AF4.
> +
> +The size of the Vendor data capability MUST be a multiple of 4 bytes.
> +
> +Reads of the Vendor data capability by the driver MUST NOT have any
> +side effects.
> +
> +\drivernormative{\subsection}{Vendor data capability}{Virtio
> +Transport Options / Virtio Over PCI Bus / PCI Device Layout /
> +Vendor data capability}
> +
> +The driver SHOULD NOT use the Vendor data capability except
> +for debugging and reporting purposes.
> +
> +The driver MUST qualify the \field{vendor_id} before
> +interpreting or writing into the Vendor data capability.
> +
> \subsubsection{PCI configuration access capability}\label{sec:Virtio
> Transport Options / Virtio Over PCI Bus / PCI Device Layout / PCI
> configuration access capability}
>
> The VIRTIO_PCI_CAP_PCI_CFG capability
> --
> MST
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [virtio] [PATCH] pci: strengthen requirement of the correct subsystem id
On Mon, Oct 28, 2019 at 12:12:49PM -0400, Michael S. Tsirkin wrote:
> If a hardware implementation of virtio does not have
> the correct subsystem id, then drivers can't report
> ir properly, or detect and work around bugs.
> Change the requirement from MAY to SHOULD.
>
> We can't make it a MUST since we did not require this
> historically.
>
> Signed-off-by: Michael S. Tsirkin
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/61
> ---
> content.tex | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/content.tex b/content.tex
> index 4bcb728..8f1518c 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -562,7 +562,7 @@ \subsection{PCI Device Discovery}\label{sec:Virtio
> Transport Options / Virtio Ov
> For example, the network card device with the Virtio Device ID 1
> has the PCI Device ID 0x1041 or the Transitional PCI Device ID 0x1000.
>
> -The PCI Subsystem Vendor ID and the PCI Subsystem Device ID MAY reflect
> +The PCI Subsystem Vendor ID and the PCI Subsystem Device ID SHOULD reflect
> the PCI Vendor and Device ID of the environment (for informational purposes
> by the driver).
>
> Non-transitional devices SHOULD have a PCI Device ID in the range
> --
> MST
>
>
> -
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] [PATCH v3] content: document speed, duplex
Document as used by Linux.
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/59
Signed-off-by: Michael S. Tsirkin
---
changes from v2
- address comments by Cornelia
- fix more typos
- consistent upper/lower case for hex values
- explicitly ask that devices use 0x for unknown speed
(this is what Linux uses)
content.tex | 33 +
1 file changed, 33 insertions(+)
diff --git a/content.tex b/content.tex
index bff80d0..678afbe 100644
--- a/content.tex
+++ b/content.tex
@@ -2892,6 +2892,7 @@ \subsection{Feature bits}\label{sec:Device Types /
Network Device / Feature bits
\item[VIRTIO_NET_F_STANDBY(62)] Device may act as a standby for a primary
device with the same MAC address.
+\item[VIRTIO_NET_F_SPEED_DUPLEX(63)] Device reports speed and duplex.
\end{description}
\subsubsection{Feature bit requirements}\label{sec:Device Types / Network
Device / Feature bits / Feature bit requirements}
@@ -2951,12 +2952,27 @@ \subsection{Device configuration
layout}\label{sec:Device Types / Network Device
VIRTIO_NET_F_MTU is set. This field specifies the maximum MTU for the driver to
use.
+The following two fields, \field{speed} and \field{duplex}, only
+exist if VIRTIO_NET_F_SPEED_DUPLEX is set.
+
+\field{speed} contains the device speed, in units of 1 MByte, 0
+to 0x7, or 0xf for unknown speed.
+
+\field{duplex} has the values of 0x00 for full duplex, 0x01 for
+half duplex and 0xff for unknown duplex state.
+
+Neither \field{speed} not \field{duplex} changes as long as
+VIRTIO_NET_S_LINK_UP is set.
+
\begin{lstlisting}
struct virtio_net_config {
u8 mac[6];
le16 status;
le16 max_virtqueue_pairs;
le16 mtu;
+le32 speed;
+u8 duplex;
+
};
\end{lstlisting}
@@ -2985,6 +3001,18 @@ \subsection{Device configuration
layout}\label{sec:Device Types / Network Device
If the driver negotiates the VIRTIO_NET_F_STANDBY feature, the device MAY act
as a standby device for a primary device with the same MAC address.
+If VIRTIO_NET_F_SPEED_DUPLEX has been negotiated, \field{speed}
+MUST contain the device speed, in units of 1 MByte, 0 to
+0x7, or 0xf for unknown.
+
+If VIRTIO_NET_F_SPEED_DUPLEX has been negotiated, \field{duplex}
+MUST have the values of 0x00 for full duplex, 0x01 for half
+duplex and 0xff for unknown.
+
+If VIRTIO_NET_F_SPEED_DUPLEX has been negotiated, the device MUST
+NOT change the \field{speed} and \field{duplex} fields as long as
+VIRTIO_NET_S_LINK_UP is set in the \field{status}.
+
\drivernormative{\subsubsection}{Device configuration layout}{Device Types /
Network Device / Device configuration layout}
A driver SHOULD negotiate VIRTIO_NET_F_MAC if the device offers it.
@@ -3009,6 +3037,11 @@ \subsection{Device configuration
layout}\label{sec:Device Types / Network Device
A driver SHOULD negotiate the VIRTIO_NET_F_STANDBY feature if the device
offers it.
+If VIRTIO_NET_F_SPEED_DUPLEX has been negotiated,
+the driver MUST treat any value of \field{speed} above
+0x7fff as well as any value of \field{duplex} not
+matching 0x00 or 0x01 as an unknown value.
+
\subsubsection{Legacy Interface: Device configuration layout}\label{sec:Device
Types / Network Device / Device configuration layout / Legacy Interface: Device
configuration layout}
\label{sec:Device Types / Block Device / Feature bits / Device configuration
layout / Legacy Interface: Device configuration layout}
When using the legacy interface, transitional devices and drivers
--
MST
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
