search for: drivernorm

...SOCK_F_SEQPACKET (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 > >...

...SOCK_F_SEQPACKET (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 > >...

...ed. > > > > > \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 fo...

...ed. > > > > > \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 fo...

...IO_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 h...

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

...67,6 +67,9 @@ \subsection{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 @@...

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

...layout} @@ -3165,6 +3181,9 @@ by the driver after negotiation. The device MUST set \field{max_virtqueue_pairs} to between 1 and 0x8000 inclusive, if it offers VIRTIO_NET_F_MQ. +The device MUST set \field{default_mtu} to between 68 and 65535 +inclusive, if it offers VIRTIO_NET_F_DEFAULT_MTU. + \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. @@ -3177,6 +3196,12 @@ If the driver does not negotiate the VIRTIO_NET_F_STATUS feature, it SHOULD assume the link i...

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 is version 0.5 of the virtio-iommu specification, the paravirtualized IOMMU. This version addresses feedback from v0.4 and adds an event virtqueue. Please find the specification, LaTeX sources and pdf, at: git://linux-arm.org/virtio-iommu.git viommu/v0.5 http://linux-arm.org/git?p=virtio-iommu.git;a=blob;f=dist/v0.5/virtio-iommu-v0.5.pdf A detailed changelog since v0.4 follows. You can find

This is version 0.5 of the virtio-iommu specification, the paravirtualized IOMMU. This version addresses feedback from v0.4 and adds an event virtqueue. Please find the specification, LaTeX sources and pdf, at: git://linux-arm.org/virtio-iommu.git viommu/v0.5 http://linux-arm.org/git?p=virtio-iommu.git;a=blob;f=dist/v0.5/virtio-iommu-v0.5.pdf A detailed changelog since v0.4 follows. You can find

I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA.

I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA.