search for: subsubsection

This set of two patches adds a new field called default_mtu to the configuration area of network devices. The motivation is to allow libvirt to set initial MTU different from 1500 on guests virtual NICs. We also propose to use this new field to report MTU changes by the guest OS to the device to facilitate debugging and mtu tunning. The first patch just clarify the definition of existing fields

This set of two patches adds a new field called default_mtu to the configuration area of network devices. The motivation is to allow libvirt to set initial MTU different from 1500 on guests virtual NICs. We also propose to use this new field to report MTU changes by the guest OS to the device to facilitate debugging and mtu tunning. The first patch just clarify the definition of existing fields

...(1)] seqpacket socket type is supported. > > > \item[VIRTIO_VSOCK_F_NO_IMPLIED_STREAM (2)] stream socket type is not implied. > > > +\item[VIRTIO_VSOCK_F_DGRAM (3)] datagram socket type is supported. > > > \end{description} > > > > > > \drivernormative{\subsubsection}{Feature bits}{Device Types / Socket Device / Feature bits} > > > @@ -167,17 +168,22 @@ \subsubsection{Addressing}\label{sec:Device Types / Socket Device / Device Opera > > > consists of a (cid, port number) tuple. The header fields used for this are > > > \field{src_cid}...

...(1)] seqpacket socket type is supported. > > > \item[VIRTIO_VSOCK_F_NO_IMPLIED_STREAM (2)] stream socket type is not implied. > > > +\item[VIRTIO_VSOCK_F_DGRAM (3)] datagram socket type is supported. > > > \end{description} > > > > > > \drivernormative{\subsubsection}{Feature bits}{Device Types / Socket Device / Feature bits} > > > @@ -167,17 +168,22 @@ \subsubsection{Addressing}\label{sec:Device Types / Socket Device / Device Opera > > > consists of a (cid, port number) tuple. The header fields used for this are > > > \field{src_cid}...

...; > > \item[VIRTIO_VSOCK_F_NO_IMPLIED_STREAM (2)] stream socket type is not implied. > > > > > +\item[VIRTIO_VSOCK_F_DGRAM (3)] datagram socket type is supported. > > > > > \end{description} > > > > > > > > > > \drivernormative{\subsubsection}{Feature bits}{Device Types / Socket Device / Feature bits} > > > > > @@ -167,17 +168,22 @@ \subsubsection{Addressing}\label{sec:Device Types / Socket Device / Device Opera > > > > > consists of a (cid, port number) tuple. The header fields used for this are > >...

...; > > \item[VIRTIO_VSOCK_F_NO_IMPLIED_STREAM (2)] stream socket type is not implied. > > > > > +\item[VIRTIO_VSOCK_F_DGRAM (3)] datagram socket type is supported. > > > > > \end{description} > > > > > > > > > > \drivernormative{\subsubsection}{Feature bits}{Device Types / Socket Device / Feature bits} > > > > > @@ -167,17 +168,22 @@ \subsubsection{Addressing}\label{sec:Device Types / Socket Device / Device Opera > > > > > consists of a (cid, port number) tuple. The header fields used for this are > >...

...LIED_STREAM (2)] stream socket type is not implied. > > > > > > > +\item[VIRTIO_VSOCK_F_DGRAM (3)] datagram socket type is supported. > > > > > > > \end{description} > > > > > > > > > > > > > > \drivernormative{\subsubsection}{Feature bits}{Device Types / Socket Device / Feature bits} > > > > > > > @@ -167,17 +168,22 @@ \subsubsection{Addressing}\label{sec:Device Types / Socket Device / Device Opera > > > > > > > consists of a (cid, port number) tuple. The header fields used fo...

...nnel. + +\item[VIRTIO_NET_F_DEFAULT_MTU(24)] Default MTU is supported. If + offered by the device, device advises driver about initial MTU to + be used. If negotiated, the driver uses \field{default_mtu} as + an initial value and reports MTU changes to the device. + \end{description} \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device / Feature bits / Feature bit requirements} @@ -3128,6 +3134,7 @@ struct virtio_net_config { u8 mac[6]; le16 status; le16 max_virtqueue_pairs; + le16 default_mtu; }; \end{lstlisting} @@ -3158,6 +3...

All sounds good to me. I actually did try to follow the Python style when I used the ^^^ thingies for the questions (they're called subsubsections). 4. I'm not sure exactly how to markup the questions. The sphinx FAQ ( > http://sphinx.pocoo.org/faq.html) marks it up as a definition list > (ctrl-f "definition list" http://sphinx.pocoo.org/rest.html). On the > other hand, the Python FAQs (e.g. > http://docs.python.or...

This is the continuation of my proposal for virtio-iommu, the para- virtualized IOMMU. Here is a summary of the changes since last time [1]: * The virtio-iommu document now resembles an actual specification. It is split into a formal description of the virtio device, and implementation notes. Please find sources and binaries at [2]. * Added a probe request to describe to the guest different

This is the continuation of my proposal for virtio-iommu, the para- virtualized IOMMU. Here is a summary of the changes since last time [1]: * The virtio-iommu document now resembles an actual specification. It is split into a formal description of the virtio device, and implementation notes. Please find sources and binaries at [2]. * Added a probe request to describe to the guest different

...is programmed by software either into the IRQ chip or -the IOMMU. Section \ref{sec:viommu / MSI / IRQ remapping} describes how to use -the remapping feature of virtio-iommu. +the IOMMU. This is shown in section \ref{sec:viommu / MSI / IRQ remapping} but +isn't yet supported by virtio-iommu. \subsubsection{Address bypass}\label{sec:viommu / MSI / Address bypass} @@ -66,8 +62,8 @@ struct __attribute__((packed)) { }, .mem = { .subtype = VIRTIO_IOMMU_RESV_MEM_T_MSI, - .addr = 0xfee00000, - .size = 0x00100000, + .start = 0xfee00000, + .end = 0xfeefffff, }, }; \end{lstlisting} @@ -90,...

...bsection{Feature bits}\label{sec:Device Types / IOMMU Device / Feature bits} \item[VIRTIO_IOMMU_F_MMIO (5)] The VIRTIO_IOMMU_MAP_F_MMIO flag is available. + +\item[VIRTIO_IOMMU_F_TOPOLOGY (6)] + Topology description is available at \field{topo_offset}. \end{description} \drivernormative{\subsubsection}{Feature bits}{Device Types / IOMMU Device / Feature bits} @@ -97,6 +100,7 @@ \subsection{Device configuration layout}\label{sec:Device Types / IOMMU Device / le32 end; } domain_range; le32 probe_size; + le16 topo_offset; }; \end{lstlisting} @@ -141,6 +145,90 @@ \subsection{Device i...

...d. (C:\usr\texmf\tex\latex\base\article.cls Document Class: article 2004/02/16 v1.4f Standard LaTeX document class (C:\usr\texmf\tex\latex\base\size10.clo File: size10.clo 2004/02/16 v1.4f Standard LaTeX file (size option) ) \c at part=\count79 \c at section=\count80 \c at subsection=\count81 \c at subsubsection=\count82 \c at paragraph=\count83 \c at subparagraph=\count84 \c at figure=\count85 \c at table=\count86 \abovecaptionskip=\skip41 \belowcaptionskip=\skip42 \bibindent=\dimen102 ) (C:\usr\texmf\tex\latex\ltxmisc\a4wide.sty Package: a4wide 1994/08/30 (C:\usr\texmf\tex\latex\ntgclass\a4.sty Package:...

..._MTU(24)] Default MTU is supported. If > + offered by the device, device advises driver about initial MTU to > + be used. If negotiated, the driver uses \field{default_mtu} as > + an initial value and reports MTU changes to the device. > + > \end{description} > > \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device / Feature bits / Feature bit requirements} > @@ -3128,6 +3134,7 @@ struct virtio_net_config { > u8 mac[6]; > le16 status; > le16 max_virtqueue_pairs; > + le16 default_mtu; Looks like...

...n, loaded. (C:\texmf\tex\latex\base\article.cls Document Class: article 2001/04/21 v1.4e Standard LaTeX document class (C:\texmf\tex\latex\base\size10.clo File: size10.clo 2001/04/21 v1.4e Standard LaTeX file (size option) ) \c at part=\count79 \c at section=\count80 \c at subsection=\count81 \c at subsubsection=\count82 \c at paragraph=\count83 \c at subparagraph=\count84 \c at figure=\count85 \c at table=\count86 \abovecaptionskip=\skip41 \belowcaptionskip=\skip42 \bibindent=\dimen102 ) ! Missing \endcsname inserted. <to be read again> \protect l.4 \begin {document} ?...

...33 + +\end_layout + +\begin_layout Description + +\change_inserted -1930653948 1358319080 +VIRTIO_NET_F_CTRL_MAC_ADDR(23) Set MAC address. \change_unchanged \end_layout @@ -5284,7 +5293,11 @@ The class VIRTIO_NET_CTRL_RX has two commands: VIRTIO_NET_CTRL_RX_PROMISC \end_layout \begin_layout Subsubsection* -Setting MAC Address Filtering +Setting MAC Address +\change_deleted -1930653948 1358318470 + Filtering +\change_unchanged + \end_layout \begin_layout Standard @@ -5324,6 +5337,17 @@ struct virtio_net_ctrl_mac { \begin_layout Plain Layout #define VIRTIO_NET_CTRL_MAC_TABLE_SET 0 +\...

...33 + +\end_layout + +\begin_layout Description + +\change_inserted -1930653948 1358319080 +VIRTIO_NET_F_CTRL_MAC_ADDR(23) Set MAC address. \change_unchanged \end_layout @@ -5284,7 +5293,11 @@ The class VIRTIO_NET_CTRL_RX has two commands: VIRTIO_NET_CTRL_RX_PROMISC \end_layout \begin_layout Subsubsection* -Setting MAC Address Filtering +Setting MAC Address +\change_deleted -1930653948 1358318470 + Filtering +\change_unchanged + \end_layout \begin_layout Standard @@ -5324,6 +5337,17 @@ struct virtio_net_ctrl_mac { \begin_layout Plain Layout #define VIRTIO_NET_CTRL_MAC_TABLE_SET 0 +\...

From: Dmitry Fleytman <dfleytma at redhat.com> V2 changes: 1. _GUEST_ added to command and feature names 2. Live migration logic fixed Reported-by: Michael S. Tsirkin <mst at redhat.com> One of recently introduced Windows features (RSC) requires network driver to be able to enable and disable HW LRO offload on the fly without device reinitialization. Current Virtio

From: Dmitry Fleytman <dfleytma at redhat.com> V2 changes: 1. _GUEST_ added to command and feature names 2. Live migration logic fixed Reported-by: Michael S. Tsirkin <mst at redhat.com> One of recently introduced Windows features (RSC) requires network driver to be able to enable and disable HW LRO offload on the fly without device reinitialization. Current Virtio