LXCR-8047 finished corrections to the latest version of the arm guide

7 files changed, 338 insertions, 287 deletions

diff --git a/doc/book-enea-nfv-access-guide/doc/benchmarks.xml b/doc/book-enea-nfv-access-guide/doc/benchmarks.xml
index def0f89..c9f042e 100644
--- a/doc/book-enea-nfv-access-guide/doc/benchmarks.xml
+++ b/doc/book-enea-nfv-access-guide/doc/benchmarks.xml
@@ -14,7 +14,7 @@
       <title>Hardware Setup</title>
 
       <tgroup cols="2">
-        <colspec align="left"/>
+        <colspec align="left" />
 
         <thead>
           <row>
@@ -124,7 +124,7 @@ rcu-nocbs=1-23 rcu_nocb_poll clocksource=tsc tsc=reliable nohpet \
 nosoftlockup audit=0 nmi_watchdog=0; setenv satapart 2; run bootsata'
 run boot_board</programlisting></para>
 
-          <para>Configure hugepages and set up DPDK:<programlisting>echo 4 &gt; /proc/sys/vm/nr_hugepages
+          <para>Configure hugepages and set up the DPDK:<programlisting>echo 4 &gt; /proc/sys/vm/nr_hugepages
 modprobe vfio-pci
 ifconfig enP1p1s0f1 down
 dpdk-devbind -b vfio-pci 0001:01:00.1</programlisting>Run
@@ -148,9 +148,9 @@ nosoftlockup audit=0 nmi_watchdog=0; setenv satapart 2; run bootsata'
 run boot_board</programlisting>
 
           <para>It is expected that a NFV Access guest image is present on the
-          target. </para>
+          target.</para>
 
-          <para>Set up DPDK and configure the OVS bridge:<programlisting># Clean up old OVS old config
+          <para>Set up the DPDK and configure the OVS bridge:<programlisting># Clean up old OVS old config
 killall ovsdb-server ovs-vswitchd
 rm -rf /etc/openvswitch/*
 rm -rf /var/run/openvswitch/*
@@ -439,14 +439,14 @@ start</programlisting><table>
 
           <para>Start by following the steps below:</para>
 
-          <para>Boot the board using the following U-Boot commands: </para>
+          <para>Boot the board using the following U-Boot commands:</para>
 
           <programlisting>setenv boot_board 'setenv userbootparams nohz_full=1-23 isolcpus=1-23 \
 rcu-nocbs=1-23 rcu_nocb_poll clocksource=tsc tsc=reliable nohpet \
 nosoftlockup audit=0 nmi_watchdog=0; setenv satapart 2; run bootsata'
 run boot_board</programlisting>
 
-          <para>Configure hugepages and set up DPDK:<programlisting>echo 4 &gt; /proc/sys/vm/nr_hugepages
+          <para>Configure hugepages and set up the DPDK:<programlisting>echo 4 &gt; /proc/sys/vm/nr_hugepages
 modprobe vfio-pci
 ifconfig enP1p1s0f1 down
 dpdk-devbind -b vfio-pci 0001:01:00.1</programlisting>Run
@@ -469,7 +469,7 @@ rcu-nocbs=1-23 rcu_nocb_poll clocksource=tsc tsc=reliable nohpet \
 nosoftlockup audit=0 nmi_watchdog=0; setenv satapart 2; run bootsata'
 run boot_board</programlisting>
 
-          <para>Set up DPDK and configure the OVS bridge:<programlisting># Clean up old OVS old config
+          <para>Set up the DPDK and configure the OVS bridge:<programlisting># Clean up old OVS old config
 killall ovsdb-server ovs-vswitchd
 rm -rf /etc/openvswitch/*
 rm -rf /var/run/openvswitch/*
@@ -520,8 +520,8 @@ ovs-ofctl add-flow ovsbr0 in_port=2,action=output:1</programlisting>Import a
           new console to the host and start the second Docker
           instance:<programlisting>docker run -v /var/run/openvswitch/:/var/run/openvswitch/ \
     -v /dev/hugepages/:/dev/hugepages/ nfv_container /bin/bash</programlisting>In
-          the second container start testpmd:<programlisting>testpmd -c 0x0F --file-prefix prog2 --socket-mem 512 --no-pci /
---vdev=virtio_user0,path=/var/run/openvswitch/vhost-user2 /
+          the second container start testpmd:<programlisting>testpmd -c 0x0F --file-prefix prog2 --socket-mem 512 --no-pci \
+--vdev=virtio_user0,path=/var/run/openvswitch/vhost-user2 \
 -d /usr/lib/librte_pmd_virtio.so.1.1 -- -i --disable-hw-vlan</programlisting>Start
           testpmd in the second Docker container:<programlisting>testpmd -c 0x30 -n 4 --file-prefix prog1  --socket-mem 512 \
     --no-pci --vdev=virtio_user0,path=/var/run/openvswitch/vhost-user2 \
@@ -693,7 +693,7 @@ rcu-nocbs=1-23 rcu_nocb_poll clocksource=tsc tsc=reliable nohpet \
 nosoftlockup audit=0 nmi_watchdog=0; setenv satapart 2; run bootsata'
 run boot_board</programlisting></para>
 
-          <para>Configure hugepages and set up DPDK:<programlisting>echo 4 &gt; /proc/sys/vm/nr_hugepages
+          <para>Configure hugepages and set up the DPDK:<programlisting>echo 4 &gt; /proc/sys/vm/nr_hugepages
 modprobe vfio-pci
 ifconfig enP1p1s0f1 down
 dpdk-devbind -b vfio-pci 0001:01:00.1</programlisting>Run
@@ -715,7 +715,7 @@ nosoftlockup audit=0 nmi_watchdog=0; setenv satapart 2; run bootsata'
 run boot_board</programlisting>Kill unnecessary services: <programlisting>killall ovsdb-server ovs-vswitchd
 rm -rf /etc/openvswitch/*
 rm -rf /var/run/openvswitch/*
-mkdir -p /var/run/openvswitch</programlisting>Configure hugepages, set up
+mkdir -p /var/run/openvswitch</programlisting>Configure hugepages, set up the
           DPDK:<programlisting>echo 20 &gt; /proc/sys/vm/nr_hugepages
 modprobe vfio-pci
 dpdk-devbind --bind=vfio-pci 0001:01:00.1</programlisting>Configure
@@ -742,7 +742,7 @@ ovs-ofctl del-flows ovsbr0
 ovs-ofctl add-flow ovsbr0 in_port=1,action=output:2
 ovs-ofctl add-flow ovsbr0 in_port=2,action=output:1</programlisting>Create an
           XML file with the content below (e.g.
-          /home/root/guest.xml):<programlisting>&lt;domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'&gt;
+          <filename>/home/root/guest.xml</filename>):<programlisting>&lt;domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'&gt;
   &lt;name&gt;nfv-ovs-vm&lt;/name&gt;
   &lt;uuid&gt;ed204646-1ad5-11e7-93ae-92361f002671&lt;/uuid&gt;
   &lt;memory unit='KiB'&gt;4194304&lt;/memory&gt;
@@ -757,7 +757,9 @@ ovs-ofctl add-flow ovsbr0 in_port=2,action=output:1</programlisting>Create an
   &lt;os&gt;
     &lt;type arch='aarch64' machine='virt,gic_version=3'&gt;hvm&lt;/type&gt;
     &lt;kernel&gt;Image&lt;/kernel&gt;
-    &lt;cmdline&gt;root=/dev/vda console=ttyAMA0,115200n8 maxcpus=24 coherent_pool=16M debug hugepagesz=512M hugepages=3 audit=0 isolcpus=1 nohz_full=1 rcu_nocbs=1 irqaffinity=0&lt;/cmdline&gt;
+    &lt;cmdline&gt;root=/dev/vda console=ttyAMA0,115200n8 maxcpus=24 coherent_pool=16M \
+    debug hugepagesz=512M hugepages=3 audit=0 isolcpus=1 nohz_full=1 rcu_nocbs=1 \
+    irqaffinity=0&lt;/cmdline&gt;
     &lt;boot dev='hd'/&gt;
   &lt;/os&gt;
 
@@ -810,19 +812,20 @@ ovs-ofctl add-flow ovsbr0 in_port=2,action=output:1</programlisting>Create an
      &lt;qemu:arg value='type=vhost-user,id=hostnet0,chardev=charnet0'/&gt;
      
      &lt;qemu:arg value='-device'/&gt;
-     &lt;qemu:arg value='virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:00:00:01,bus=pcie.0,addr=0x2'/&gt;
+     &lt;qemu:arg value='virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:00:00:01,
+     bus=pcie.0,addr=0x2'/&gt;
   &lt;/qemu:commandline&gt;
 &lt;/domain&gt;</programlisting></para>
 
-          <para>Start the virtual machine, by running:</para>
+          <para>Start the virtual machine by running:</para>
 
           <para><programlisting>virsh create /home/root/guest.xml</programlisting></para>
 
-          <para>Connect to the virtual machines console:</para>
+          <para>Connect to the virtual machine console:</para>
 
           <para><programlisting>virsh console nfv-ovs-vm</programlisting></para>
 
-          <para>Inside the VM, configure DPDK: <programlisting>ifconfig enp0s2 down
+          <para>Inside the VM, configure the DPDK: <programlisting>ifconfig enp0s2 down
 echo 1 &gt; /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
 modprobe vfio-pci
 dpdk-devbind -b vfio-pci 0000:00:02.0</programlisting>Inside the VM, start
@@ -1090,7 +1093,7 @@ show port stats 0</programlisting><table>
           <programlisting>setenv boot_board 'setenv userbootparams nohz_full=1-23 isolcpus=1-23 \
 rcu-nocbs=1-23 rcu_nocb_poll clocksource=tsc tsc=reliable nohpet \
 nosoftlockup audit=0 nmi_watchdog=0; setenv satapart 2; run bootsata'
-run boot_board</programlisting>Configure hugepages and set up
+run boot_board</programlisting>Configure hugepages and set up the
           DPDK:<programlisting>echo 4 &gt; /proc/sys/vm/nr_hugepages
 modprobe vfio-pci
 ifconfig enP1p1s0f1 down
@@ -1107,28 +1110,29 @@ dpdk-devbind -b vfio-pci 0001:01:00.1</programlisting>Run
           <para>Start by doing the following:</para>
 
           <para>SSD boot using the following <literal>grub.cfg</literal>
-          entry: <programlisting>linux (hd0,gpt3)/boot/bzImage root=/dev/sda3 ip=dhcp nohz_full=1-7 /
-isolcpus=1-7 rcu-nocbs=1-7 rcu_nocb_poll intel_pstate=disable /
-clocksource=tsc tsc=reliable nohpet nosoftlockup intel_idle.max_cstate=0 /
-processor.max_cstate=0 mce=ignore_ce audit=0 nmi_watchdog=0 iommu=pt /
-intel_iommu=on  hugepagesz=1GB hugepages=8 default_hugepagesz=1GB /
+          entry: <programlisting>linux (hd0,gpt3)/boot/bzImage root=/dev/sda3 ip=dhcp nohz_full=1-7 \
+isolcpus=1-7 rcu-nocbs=1-7 rcu_nocb_poll intel_pstate=disable \
+clocksource=tsc tsc=reliable nohpet nosoftlockup intel_idle.max_cstate=0 \
+processor.max_cstate=0 mce=ignore_ce audit=0 nmi_watchdog=0 iommu=pt \
+intel_iommu=on  hugepagesz=1GB hugepages=8 default_hugepagesz=1GB \
 hugepagesz=2M hugepages=2048 vfio_iommu_type1.allow_unsafe_interrupts=1</programlisting>Kill
           Services:<programlisting>killall ovsdb-server ovs-vswitchd
 rm -rf /etc/openvswitch/*
-mkdir -p /var/run/openvswitch</programlisting>Configure hugepages, set up
+mkdir -p /var/run/openvswitch</programlisting>Configure hugepages, set up the
           DPDK:<programlisting>echo 20 &gt; /proc/sys/vm/nr_hugepages
 modprobe vfio-pci
-dpdk-devbind --bind=vfio-pci 0001:01:00.1</programlisting>Configure
+dpdk-devbind --bind=vfio-pci 0001:01:00.1</programlisting>Configure the
           OVS:<programlisting>export DB_SOCK=/var/run/openvswitch/db.sock
 ovsdb-tool create /etc/openvswitch/conf.db /usr/share/openvswitch/vswitch.ovsschema
-ovsdb-server --remote=punix:$DB_SOCK --remote=db:Open_vSwitch,Open_vSwitch,manager_options \
-    --pidfile --detach
+ovsdb-server --remote=punix:$DB_SOCK \
+    --remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach
 ovs-vsctl --no-wait init
 ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-lcore-mask=0x10
 ovs-vsctl --no-wait set Open_vSwitch . other_config:pmd-cpu-mask=0xc
 ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-socket-mem=2048
 ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true
-ovs-vswitchd unix:$DB_SOCK --pidfile --detach --log-file=/var/log/openvswitch/ovs-vswitchd.log
+ovs-vswitchd unix:$DB_SOCK --pidfile --detach \
+    --log-file=/var/log/openvswitch/ovs-vswitchd.log
 
 ovs-vsctl add-br ovsbr0 -- set bridge ovsbr0 datapath_type=netdev
 ovs-vsctl add-port ovsbr0 dpdk0 -- set Interface dpdk0 type=dpdk \
@@ -1157,7 +1161,9 @@ ovs-ofctl add-flow ovsbr0 in_port=2,action=output:3</programlisting>Create an
   &lt;os&gt;
     &lt;type arch='aarch64' machine='virt,gic_version=3'&gt;hvm&lt;/type&gt;
     &lt;kernel&gt;Image&lt;/kernel&gt;
-    &lt;cmdline&gt;root=/dev/vda console=ttyAMA0,115200n8 maxcpus=24 coherent_pool=16M debug hugepagesz=512M hugepages=3  audit=0 isolcpus=1 nohz_full=1 rcu_nocbs=1 irqaffinity=0&lt;/cmdline&gt;
+    &lt;cmdline&gt;root=/dev/vda console=ttyAMA0,115200n8 maxcpus=24 coherent_pool=16M \
+    debug hugepagesz=512M hugepages=3  audit=0 isolcpus=1 nohz_full=1 rcu_nocbs=1 \
+    irqaffinity=0&lt;/cmdline&gt;
     &lt;boot dev='hd'/&gt;
   &lt;/os&gt;
 
@@ -1210,21 +1216,20 @@ ovs-ofctl add-flow ovsbr0 in_port=2,action=output:3</programlisting>Create an
      &lt;qemu:arg value='type=vhost-user,id=hostnet0,chardev=charnet0'/&gt;
 
      &lt;qemu:arg value='-device'/&gt;
-     &lt;qemu:arg value='virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:00:00:01,bus=pcie.0,addr=0x2'/&gt;
+     &lt;qemu:arg value='virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:00:00:01,/
+     bus=pcie.0,addr=0x2'/&gt;
   &lt;/qemu:commandline&gt;
-&lt;/domain&gt;
-</programlisting></para>
+&lt;/domain&gt;</programlisting></para>
 
-          <para>Connect to the first virtual machines console, by
-          running:</para>
+          <para>The first virtual machine shall be called VM1. Connect to the
+          first virtual machine console, by running:</para>
 
           <para><programlisting>virsh console nfv-ovs-vm1</programlisting></para>
 
-          <para>The first virtual machine shall be called VM1.</para>
-
-          <para>Connect to Target 2 through a new SSH session and run launch a
-          second VM by creating another XML file and running <command>virsh
-          create &lt;XML_FILE2&gt;</command><programlisting>&lt;domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'&gt;
+          <para>Connect to Target 2 through a new <literal>SSH</literal>
+          session, and launch a second VM by creating another XML file and
+          running <command>virsh create
+          &lt;XML_FILE2&gt;:</command><programlisting>&lt;domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'&gt;
   &lt;name&gt;nfv-ovs-vm2&lt;/name&gt;
   &lt;uuid&gt;ed204646-1ad5-11e7-93ae-92361f002623&lt;/uuid&gt;
   &lt;memory unit='KiB'&gt;4194304&lt;/memory&gt;
@@ -1239,7 +1244,9 @@ ovs-ofctl add-flow ovsbr0 in_port=2,action=output:3</programlisting>Create an
   &lt;os&gt;
     &lt;type arch='aarch64' machine='virt,gic_version=3'&gt;hvm&lt;/type&gt;
     &lt;kernel&gt;Image&lt;/kernel&gt;
-    &lt;cmdline&gt;root=/dev/vda console=ttyAMA0,115200n8 maxcpus=24 coherent_pool=16M debug hugepagesz=512M hugepages=3  audit=0 isolcpus=1 nohz_full=1 rcu_nocbs=1 irqaffinity=0&lt;/cmdline&gt;
+    &lt;cmdline&gt;root=/dev/vda console=ttyAMA0,115200n8 maxcpus=24 coherent_pool=16M \
+    debug hugepagesz=512M hugepages=3 audit=0 isolcpus=1 nohz_full=1 rcu_nocbs=1 \
+    irqaffinity=0&lt;/cmdline&gt;
     &lt;boot dev='hd'/&gt;
   &lt;/os&gt;
 
@@ -1292,26 +1299,24 @@ ovs-ofctl add-flow ovsbr0 in_port=2,action=output:3</programlisting>Create an
      &lt;qemu:arg value='type=vhost-user,id=hostnet0,chardev=charnet1'/&gt;
 
      &lt;qemu:arg value='-device'/&gt;
-     &lt;qemu:arg value='virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:00:00:02,bus=pcie.0,addr=0x2'/&gt;
+     &lt;qemu:arg value='virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:00:00:02,/
+     bus=pcie.0,addr=0x2'/&gt;
   &lt;/qemu:commandline&gt;
-&lt;/domain&gt;
-</programlisting></para>
+&lt;/domain&gt;</programlisting></para>
 
-          <para>Connect to the second virtual machines console, by
-          running:</para>
+          <para>The second virtual machine shall be called VM2. Connect to the
+          second virtual machine console, by running:</para>
 
           <para><programlisting>virsh console nfv-ovs-vm2</programlisting></para>
 
-          <para>The second virtual machine shall be called VM2.</para>
-
-          <para>Configure DPDK inside VM1:<programlisting>ifconfig enp0s2 down
+          <para>Configure the DPDK inside VM1:<programlisting>ifconfig enp0s2 down
 echo 1 &gt; /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
 modprobe vfio-pci
 dpdk-devbind -b vfio-pci 0000:00:02.0</programlisting>Run testpmd inside
           VM1:<programlisting>testpmd -v -c 0x3 -n 4 -d /usr/lib/librte_pmd_virtio.so.1.1 \
     -w 0000:00:02.0 -- -i --disable-hw-vlan-filter \
     --no-flush-rx --port-topology=chained</programlisting>Start testpmd inside
-          VM1:<programlisting>start</programlisting>Configure DPDK inside
+          VM1:<programlisting>start</programlisting>Configure the DPDK inside
           VM2:<programlisting>ifconfig enp0s2 down
 echo 1 &gt; /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
 modprobe vfio-pci
@@ -1321,8 +1326,8 @@ dpdk-devbind -b vfio-pci 0000:00:02.0</programlisting>Run testpmd inside
     --no-flush-rx --port-topology=chained</programlisting>Set VM2 for
           termination and start testpmd:<programlisting>set fwd rxonly
 start</programlisting>On target 1, start pktgen traffic:<programlisting>start 0</programlisting>Use
-          this command to refresh testpmd display in VM1 and VM2 and note the
-          highest values:<programlisting>show port stats 0</programlisting>To
+          this command to refresh the testpmd display in VM1 and VM2 and note
+          the highest values:<programlisting>show port stats 0</programlisting>To
           stop traffic from pktgen, in order to choose a different frame
           size:<programlisting>stop 0</programlisting>To clear numbers in
           testpmd:<programlisting>clear port stats
@@ -1337,7 +1342,8 @@ show port stats 0</programlisting>For VM1, we record the stats relevant for
 
           <para>Only Rx-pps and Tx-pps numbers are important here, they change
           every time stats are displayed as long as there is traffic. Run the
-          command a few times and pick the best (maximum) values seen.</para>
+          command a few times and pick the best (maximum) values
+          observed.</para>
 
           <para>For VM2, we record the stats relevant for <emphasis
           role="bold">termination</emphasis>:</para>
@@ -1473,4 +1479,4 @@ show port stats 0</programlisting>For VM1, we record the stats relevant for
       </section>
     </section>
   </section>
-</chapter>
+</chapter>
\ No newline at end of file
diff --git a/doc/book-enea-nfv-access-guide/doc/dpdk.xml b/doc/book-enea-nfv-access-guide/doc/dpdk.xml
index 736c8f1..bc3f479 100644
--- a/doc/book-enea-nfv-access-guide/doc/dpdk.xml
+++ b/doc/book-enea-nfv-access-guide/doc/dpdk.xml
@@ -67,6 +67,10 @@ mount -t hugetlbfs nodev /mnt/huge</programlisting>
         url="http://dpdk.org/doc/guides-17.08/tools/devbind.html">http://dpdk.org/doc/guides-17.08/tools/devbind.html</ulink>
         for more information.</para>
       </listitem>
+
+      <listitem>
+        <para>VFIO-NOMMU needs to be set if run on VM: <programlisting>echo 1 &gt; /sys/module/vfio/parameters/enable_unsafe_noiommu_mode</programlisting></para>
+      </listitem>
     </orderedlist>
 
     <para>To print the current status of all known network
@@ -88,14 +92,15 @@ mount -t hugetlbfs nodev /mnt/huge</programlisting>
     <orderedlist>
       <listitem>
         <para>Setup DPDK on both boards, following the instructions in <xref
-        linkend="dpdk-setup"/>.</para>
+        linkend="dpdk-setup" />.</para>
       </listitem>
 
       <listitem>
         <para>On board 1, start the Pktgen application:</para>
 
         <programlisting>cd /usr/share/apps/pktgen/
-./pktgen -v -c 0x7 -n 4 --proc-type auto -d /usr/lib/librte_pmd_thunderx_nicvf.so.1.1 -w &lt;PCI device number&gt; -- -P -m "[1:2].0"</programlisting>
+./pktgen -v -c 0x7 -n 4 --proc-type auto -d \
+/usr/lib/librte_pmd_thunderx_nicvf.so.1.1 -w &lt;PCI device number&gt; -- -P -m "[1:2].0"</programlisting>
 
         <para>In the Pktgen console, run:</para>
 
@@ -108,8 +113,8 @@ mount -t hugetlbfs nodev /mnt/huge</programlisting>
       <listitem>
         <para>On board 2, start the testpmd application:</para>
 
-        <programlisting>testpmd -v -c 0x3 -n 4 -d /usr/lib/librte_pmd_thunderx_nicvf.so.1.1 -w &lt;PCI device number&gt; -- -i --disable-hw-vlan-filter  --no-flush-rx --port-topology=chained
-</programlisting>
+        <programlisting>testpmd -v -c 0x3 -n 4 -d /usr/lib/librte_pmd_thunderx_nicvf.so.1.1 -w &lt;PCI device \
+number&gt; -- -i --disable-hw-vlan-filter  --no-flush-rx --port-topology=chained</programlisting>
 
         <para>For more information, refer to the testpmd application user
         guide: <ulink
@@ -117,4 +122,4 @@ mount -t hugetlbfs nodev /mnt/huge</programlisting>
       </listitem>
     </orderedlist>
   </section>
-</chapter>
+</chapter>
\ No newline at end of file
diff --git a/doc/book-enea-nfv-access-guide/doc/getting_started.xml b/doc/book-enea-nfv-access-guide/doc/getting_started.xml
index cb1de6d..74cad71 100644
--- a/doc/book-enea-nfv-access-guide/doc/getting_started.xml
+++ b/doc/book-enea-nfv-access-guide/doc/getting_started.xml
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 <chapter id="plat-release-content">
@@ -96,71 +96,96 @@
    /* GRUB EFI file */</programlisting>
   </section>
 
-  <section condition="" id="prebuilt-artifacts">
+  <section id="prebuilt-artifacts">
     <title>How to use the Prebuilt Artifacts</title>
 
     <section id="sysshell_config">
       <title>Booting NFV Access to RAM</title>
 
-      <para>NFV Access can be booted on target using the RAMDISK images.
-      Following is described how to set the environment, configure the
-      bootloader(U-Boot), load and boot the NFV Access on target. Please check
-      the <link linkend="boot_prereq">Prerequisites</link> subchapter before
-      starting boot process.</para>
-
-      <para>Connect to target over serial and stop default boot process in
-      U-Boot command line interface. Set U-Boot network configuration for the
-      ethernet port which connects the target to the network. If target is not
-      connected on a specific network, Enea provides DHCP and TFTP servers.
-      Please see <link linkend="boot_docker">Docker Installer</link>
-      subchapter about how to install them on a development host.</para>
-
-      <programlisting>&gt; setenv ethact    &lt;vnic0/vnic1&gt;
+      <para>Enea NFV Access can be booted on a target using the RAMDISK
+      images. How to set the environment, configure the bootloader (U-Boot),
+      load and boot on the target, is detailed below. Please check the <link
+      linkend="boot_prereq">Prerequisites</link> section before starting the
+      boot process.</para>
+
+      <para><emphasis role="bold">Setting up the environment and booting on
+      the target</emphasis></para>
+
+      <itemizedlist>
+        <listitem>
+          <para>Connect to the target over serial and stop the default boot
+          process in the U-Boot command line interface.</para>
+        </listitem>
+
+        <listitem>
+          <para>Set up the U-Boot network configuration for the ethernet port,
+          which connects the target to the network.</para>
+        </listitem>
+
+        <listitem>
+          <para>If the target is not connected on a specific network, Enea
+          provides DHCP and TFTP servers. Please see <link
+          linkend="boot_docker">Docker Installer</link> section, on how to
+          install these two servers on a development host.</para>
+
+          <programlisting>&gt; setenv ethact    &lt;vnic0/vnic1&gt;
 &gt; setenv gatewayip &lt;GatewayIP&gt;
 &gt; setenv serverip  &lt;TFTPserverIP&gt;
 &gt; setenv netmask   &lt;netmask&gt;
 &gt; setenv ipaddr    &lt;target IP&gt;</programlisting>
+        </listitem>
 
-      <para>Boot NFV Access images:</para>
+        <listitem>
+          <para>Boot the Enea NFV Access images:</para>
 
-      <programlisting>&gt; tftpboot $kernel_addr Image 
+          <programlisting>&gt; tftpboot $kernel_addr Image 
 &gt; setenv rootfs_addr 0x60000000
 &gt; tftpboot $rootfs_addr enea-nfv-access-cn8304.ext4.gz.u-boot
 &gt; booti $kernel_addr $rootfs_addr $fdtcontroladdr
 &gt; setenv bootargs root=/dev/ram0 rw ramdisk_size=1000000 console=ttyAMA0,115200n8 \
   earlycon=pl011,0x87e028000000 coherent_pool=16M</programlisting>
+        </listitem>
+      </itemizedlist>
 
       <section id="boot_prereq">
-        <title>Prerequisites:</title>
+        <title>Prerequisites</title>
+
+        <para>The following requirements are needed in order to successfully
+        boot Enea NFV Access to RAM:</para>
 
         <itemizedlist>
           <listitem>
-            <para>NFV Acccess images - see NFV Access release content</para>
+            <para>Enea NFV Acccess images - see the <xi:include
+            href="../../s_docbuild/olinkdb/pardoc-common.xml"
+            xmlns:xi="http://www.w3.org/2001/XInclude"
+            xpointer="element(book_enea_nfv_access_release_info/1)" />, under
+            section <emphasis role="bold">Release Content</emphasis>, for
+            details on the images provided.</para>
           </listitem>
         </itemizedlist>
 
         <itemizedlist>
           <listitem>
-            <para>DHCP server - If the board is not connected into a specific
-            network Enea provides a docker image with DHCP server. Please see
-            <link linkend="boot_docker">Docker Installer</link>
-            subchapter.</para>
+            <para>DHCP server - If the board is not connected to a specific
+            network, Enea provides a Docker image with a DHCP server. Please
+            see the <link linkend="boot_docker">Docker Installer</link>
+            section for further details.</para>
           </listitem>
         </itemizedlist>
 
         <itemizedlist>
           <listitem>
-            <para>TFTP server - If the board is not connected into a specific
-            network Enea provides a docker image with TFTP server. Please see
-            <link linkend="boot_docker">Docker Installer</link>
-            subchapter.</para>
+            <para>TFTP server - If the board is not connected to a specific
+            network, Enea provides a Docker image with a TFTP server. Please
+            see the <link linkend="boot_docker">Docker Installer</link>
+            section for further details.</para>
           </listitem>
         </itemizedlist>
 
         <itemizedlist>
           <listitem>
-            <para>The board with U-Boot connected to a development host over
-            serial and ethernet.</para>
+            <para>The reference board, with U-Boot connected to a development
+            host over serial and ethernet.</para>
           </listitem>
         </itemizedlist>
       </section>
@@ -168,41 +193,52 @@
       <section id="boot_docker">
         <title>Docker Installer</title>
 
-        <para>Enea provides a suite of tools in order to create a complete
-        boot process setup. System requirements for the development host are
-        detailed in the Enea NFV Access Release Information document included
-        with this release. All tools are leveraged by a docker image. The
-        docker image must be built and ran on development host. DHCP and TFTP
-        servers will be installed and configured in order to facilitate a
-        RAMDISK boot process on the target. Following is an example of how to
-        build and run Enea provided docker image. In this case host is
-        directly connected to target on eth1. For more details about docker
-        installer please see README file from docker installater
-        folder.</para>
+        <para>A suite of tools are provided in order to create a complete boot
+        process setup. System requirements for the development host are
+        detailed in the <xi:include
+        href="../../s_docbuild/olinkdb/pardoc-common.xml"
+        xmlns:xi="http://www.w3.org/2001/XInclude"
+        xpointer="element(book_enea_nfv_access_release_info/1)" /> included
+        with this release. </para>
+
+        <para>All tools are leveraged by a Docker image, which must be built
+        and run on a development host. DHCP and TFTP servers will be installed
+        and configured in order to facilitate a RAMDISK boot process on the
+        target. </para>
+
+        <para>The example procedure below details how to build and run a
+        provided Docker image. In this case, the host is directly connected to
+        a target on <literal>eth1</literal>. For more details about the Docker
+        installer, please see <filename>README</filename> file from the Docker
+        installer folder. </para>
+
+        <para>Prior to using this example setup, on the target side, U-Boot
+        needs to be configured with these values, before booting Linux. Note
+        that the first eth port (<literal>vnic0</literal>) is connected to a
+        network:</para>
+
+        <programlisting>&gt; setenv ethact vnic0
+&gt; setenv gatewayip 192.168.1.1
+&gt; setenv serverip 192.168.1.1
+&gt; setenv netmask 255.255.255.0
+&gt; setenv ipaddr 192.168.1.150</programlisting>
+
+        <para><emphasis role="bold">How to build and run a provided Docker
+        image</emphasis></para>
 
         <programlisting>&gt; cd nfv-access-tools/nfv-installer/docker-pxe-ramboot/
 &gt; mkdir -p ./images
 &gt; cp &lt;NFVAccessReleasePath&gt;/Image $(pwd)/images/Image
 &gt; cp &lt;NFVAccessReleasePath&gt;/enea-nfv-access-cn8304.ext4.gz.u-boot \
-     $(pwd)/images/enea-nfv-access.ext4.gz.u-boot</programlisting>
-
-        <programlisting>&gt; docker build . -t el_installer</programlisting>
-
-        <programlisting>&gt; docker run -it --net=host --privileged \
+     $(pwd)/images/enea-nfv-access.ext4.gz.u-boot
+&gt; docker build . -t el_installer
+&gt; docker run -it --net=host --privileged \
 -v $(pwd)/dhcpd.conf:/etc/dhcp/dhcpd.conf \
 -v $(pwd)/images/Image:/var/lib/tftpboot/Image \
--v $(pwd)/images/enea-nfv-access.ext4.gz.u-boot:/var/lib/tftpboot/enea-nfv-access.ext4.gz.u-boot \
-el_installer eth1</programlisting>
+-v $(pwd)/images/enea-nfv-access.ext4.gz.u-boot:/var/lib/tftpboot/ \
+enea-nfv-access.ext4.gz.u-boot
 
-        <para>Using this setup, on target side, U-Boot need to be configured
-        as following before starting to boot Linux. It was considered that the
-        first eth port(vnic0) is connected to network:</para>
-
-        <programlisting>&gt; setenv ethact vnic0
-&gt; setenv gatewayip 192.168.1.1
-&gt; setenv serverip 192.168.1.1
-&gt; setenv netmask 255.255.255.0
-&gt; setenv ipaddr 192.168.1.150</programlisting>
+el_installer eth1</programlisting>
       </section>
     </section>
   </section>
diff --git a/doc/book-enea-nfv-access-guide/doc/hypervisor_virtualization.xml b/doc/book-enea-nfv-access-guide/doc/hypervisor_virtualization.xml
index 76a2568..69057f3 100644
--- a/doc/book-enea-nfv-access-guide/doc/hypervisor_virtualization.xml
+++ b/doc/book-enea-nfv-access-guide/doc/hypervisor_virtualization.xml
@@ -4,8 +4,8 @@
 <chapter id="hypervisor_virt">
   <title>Hypervisor Virtualization</title>
 
-  <para>The KVM, Kernel-based Virtual Machine, is a virtualization
-  infrastructure for the Linux kernel which turns it into a hypervisor. KVM
+  <para>The Kernel-based Virtual Machine (KVM), is a virtualization
+  infrastructure for the Linux kernel, which turns it into a hypervisor. KVM
   requires a processor with a hardware virtualization extension.</para>
 
   <para>KVM uses QEMU, an open source machine emulator and virtualizer, to
@@ -18,15 +18,15 @@
 
     <para>QEMU can make use of KVM when running a target architecture that is
     the same as the host architecture. For instance, when running
-    qemu-system-aarch64 on an aarch64 compatible processor (containing
-    virtualization extensions AMD-V or Intel VT), you can take advantage of
-    the KVM acceleration, giving you benefit for your host and your guest
-    system.</para>
+    <filename>qemu-system-aarch64</filename> on an <literal>aarch64</literal>
+    compatible processor with Hardware Virtualization support enabled, you can
+    take advantage of the KVM acceleration, an added benefit for your host and
+    guest system.</para>
 
     <para>Enea NFV Access includes an optimized version of QEMU with KVM-only
-    support. To use KVM pass<command> --enable-kvm</command> to QEMU.</para>
+    support. To use KVM pass <command>--enable-kvm</command> to QEMU.</para>
 
-    <para>The following is an example of starting a guest:</para>
+    <para>The following is an example of starting a guest system:</para>
 
     <programlisting>taskset -c 0,1 qemu-system-aarch64 \
 -cpu host -machine virt,gic_version=3 -smp cores=2,sockets=1 \
@@ -41,63 +41,64 @@
   </section>
 
   <section id="qemu_boot">
-    <title>Main QEMU boot options</title>
+    <title>Primary QEMU boot options</title>
 
     <para>Below are detailed all the pertinent boot options for the QEMU
     emulator:</para>
 
     <itemizedlist>
       <listitem>
-        <para>SMP - at least 2 cores should be enabled in order to isolate
-        application(s) running in virtual machine(s) on specific cores for
-        better performance.</para>
+        <para>SMP - at least 2 cores should be enabled in order to isolate the
+        application(s) running in the virtual machine(s), on specific cores,
+        for better performance:</para>
 
         <programlisting>-smp cores=2,threads=1,sockets=1 \</programlisting>
       </listitem>
 
       <listitem>
-        <para>CPU affinity - associate virtual CPUs with physical CPUs and
-        optionally assign a default real time priority to the virtual CPU
-        process in the host kernel. This option allows you to start qemu vCPUs
-        on isolated physical CPUs.</para>
+        <para>CPU affinity - associate virtual CPUs with physical CPUs, and
+        optionally assign a default realtime priority to the virtual CPU
+        process in the host kernel. This option allows you to start QEMU vCPUs
+        on isolated physical CPUs:</para>
 
         <programlisting>-vcpu 0,affinity=0   \</programlisting>
       </listitem>
 
       <listitem>
-        <para>Hugepages - KVM guests can be deployed with huge page memory
-        support in order to reduce memory consumption and improve performance,
-        by reducing CPU cache usage. By using huge pages for a KVM guest, less
+        <para>Hugepages - KVM guests can be deployed with hugepage memory
+        support to reduce memory consumption and improve performance, by
+        reducing CPU cache usage. By using hugepages for a KVM guest, less
         memory is used for page tables and TLB (Translation Lookaside Buffer)
-        misses are reduced, thereby significantly increasing performance,
-        especially for memory-intensive situations.</para>
+        misses are reduced, significantly increasing performance, especially
+        for memory-intensive situations.</para>
 
         <programlisting>-object memory-backend-file,id=mem,size=4096M,mem-path=/dev/hugepages,share=on \</programlisting>
       </listitem>
 
       <listitem>
-        <para>Memory preallocation - preallocate huge pages at startup time
-        can improve performance but it may affect the qemu boot time.</para>
+        <para>Memory preallocation - preallocate hugepages at startup to
+        improve performance. This may affect QEMU boot time.</para>
 
         <programlisting>-mem-prealloc \</programlisting>
       </listitem>
 
       <listitem>
-        <para>Enable realtime characteristics - run qemu with realtime
-        features. While that mildly implies that "-realtime" alone might do
-        something, it's just an identifier for options that are partially
-        realtime. If you're running in a realtime or low latency environment,
-        you don't want your pages to be swapped out and mlock does that, thus
-        mlock=on. If you want VM density, then you may want swappable VMs,
-        thus mlock=off.</para>
+        <para>Enable realtime characteristics - run QEMU with realtime
+        features.</para>
+
+        <para>In this case, "realtime" is just an identifier for options that
+        are partially realtime. If you're running in a realtime or low latency
+        environment, and you don't want your pages to be swapped out, this can
+        be ensured by using <command>mlock=on</command>. If you want VM
+        density, then you may want swappable VMs, this can be done with
+        <command>mlock=off</command>.</para>
 
         <programlisting>-realtime mlock=on \</programlisting>
       </listitem>
     </itemizedlist>
 
-    <para>If the hardware does not have an IOMMU (known as "Intel VT-d" on
-    Intel-based machines and "AMD I/O Virtualization Technology" on AMD-based
-    machines), it will not be possible to assign devices in KVM. </para>
+    <para>If the hardware does not have an IOMMU, it will not be possible to
+    assign devices in KVM.</para>
   </section>
 
   <section id="net_in_guest">
@@ -106,15 +107,17 @@
     <section id="vhost-user-support">
       <title>Using vhost-user support</title>
 
-      <para>The goal of vhost-user is to implement a Virtio transport, staying
-      as close as possible to the vhost paradigm of using shared memory,
-      ioeventfds and irqfds. A UNIX domain socket based mechanism allows the
-      set up of resources used by a number of Vrings shared between two
-      userspace processes, which will be placed in shared memory.</para>
+      <para>The goal of <literal>vhost-user</literal> is to implement a Virtio
+      transport, staying as close as possible to the <literal>vhost</literal>
+      paradigm of using: shared memory, <literal>ioeventfds</literal> and
+      <literal>irqfds</literal>. A UNIX domain socket based mechanism, allows
+      for the set up of resources used by various <literal>Vrings</literal>
+      shared between two userspace processes, and will be placed in shared
+      memory.</para>
 
-      <para>To run QEMU with the vhost-user backend, you have to provide the
-      named UNIX domain socket which needs to be already opened by the
-      backend:</para>
+      <para>To run QEMU with the <literal>vhost-user</literal> backend, you
+      have to provide the named UNIX domain socket, which needs to already be
+      opened by the backend:</para>
 
       <programlisting>-object memory-backend-file,id=mem,size=4096M,mem-path=/dev/hugepages,share=on \
 -chardev socket,id=char0,path=/var/run/openvswitch/vhost-user1 \
@@ -123,14 +126,15 @@
 
       <para>The vHost User standard uses a client-server model. The server
       creates and manages the vHost User sockets and the client connects to
-      the sockets created by the server. It is recommended to use QEMU as
-      server so the vhost-user client can be restarted without affecting the
-      server, otherwise if the server side dies all clients need to be
-      restarted.</para>
+      the sockets created by the server. It is recommended to use QEMU as the
+      server, so that the <literal>vhost-user</literal> client can be
+      restarted without affecting the server, otherwise if the server side
+      dies, all clients need to be restarted.</para>
 
-      <para>Using vhost-user in QEMU as server will offer the flexibility to
-      stop and start the virtual machine with no impact on virtual switch from
-      the host (vhost-user-client).</para>
+      <para>Using <literal>vhost-user</literal> in QEMU will offer the
+      flexibility to stop and start the virtual machine with no impact on the
+      virtual switch from the host
+      (<literal>vhost-user-client</literal>).</para>
 
       <programlisting>-chardev socket,id=char0,path=/var/run/openvswitch/vhost-user1,server \</programlisting>
     </section>
@@ -154,17 +158,6 @@
       to appear and behave as if they were physically attached to the guest
       operating system.</para>
 
-      <para>Preparing a system for PCI passthrough:</para>
-
-      <itemizedlist>
-        <listitem>
-          <para>Allow unsafe interrupts in case the system doesn't support
-          interrupt remapping. This can be done using
-          <literal>vfio_iommu_type1.allow_unsafe_interrupts=1</literal> as a
-          boot kernel parameter.</para>
-        </listitem>
-      </itemizedlist>
-
       <para>Create guest with direct passthrough via VFIO framework like
       so:</para>
 
@@ -181,6 +174,13 @@ $ dpdk-devbind.py --bind=vfio-pci 0001:01:00.1</programlisting>
       url="http://dpdk.org/doc/guides/nics/thunderx.html">http://dpdk.org/doc/guides/nics/thunderx.html</ulink>.</para>
     </section>
 
+    <section>
+      <title>Enable VFIO-NOIOMMU mode</title>
+
+      <para>In order to run a DPDK application in VM, the VFIO-NOIOMMU needs
+      to be set: <programlisting>echo 1 &gt; /sys/module/vfio/parameters/enable_unsafe_noiommu_mode</programlisting></para>
+    </section>
+
     <section id="multiqueue">
       <title>Multi-queue</title>
 
@@ -188,7 +188,10 @@ $ dpdk-devbind.py --bind=vfio-pci 0001:01:00.1</programlisting>
       of vCPUs increases, multi-queue support can be used in QEMU.</para>
 
       <section id="qemu-multiqueue-support">
-        <title>QEMU multi queue support configuration</title>
+        <title>QEMU multi-queue support configuration</title>
+
+        <para>Below is an example of how to set up the QEMU multi-queue
+        support configuration:</para>
 
         <programlisting>-chardev socket,id=char0,path=/var/run/openvswitch/vhost-user1 \
 -netdev type=vhost-user,id=net0,chardev=char0,queues=2 \
@@ -199,15 +202,16 @@ where vectors is calculated as: 2 + 2 * queues number.</programlisting>
       <section id="inside-guest">
         <title>Inside guest</title>
 
-        <para>Linux kernel virtio-net driver (one queue is enabled by
-        default):</para>
+        <para>The Linux kernel <filename>virtio-net</filename> driver, where
+        one queue is enabled by default:</para>
 
         <programlisting>$ ethtool -L combined 2 eth0
 DPDK Virtio PMD
 $ testpmd -c 0x7 -- -i --rxq=2 --txq=2 --nb-cores=2 ...</programlisting>
 
         <para>For QEMU documentation, see: <ulink
-        url="https://qemu.weilnetz.de/doc/qemu-doc.html">https://qemu.weilnetz.de/doc/qemu-doc.html</ulink>.</para>
+        url="https://qemu.weilnetz.de/doc/qemu-doc.html">QEMU User
+        Documentation</ulink>.</para>
       </section>
     </section>
   </section>
@@ -217,22 +221,24 @@ $ testpmd -c 0x7 -- -i --rxq=2 --txq=2 --nb-cores=2 ...</programlisting>
 
     <para>One way to manage guests in Enea NFV Access is by using
     <literal>libvirt</literal>. Libvirt is used in conjunction with a daemon
-    (<literal>libvirtd</literal>) and a command line utility (virsh) to manage
-    virtualized environments.</para>
-
-    <para>The libvirt library is a hypervisor-independent virtualization API
-    and toolkit that is able to interact with the virtualization capabilities
-    of a range of operating systems. Libvirt provides a common, generic and
-    stable layer to securely manage domains on a node. As nodes may be
-    remotely located, libvirt provides all methods required to provision,
-    create, modify, monitor, control, migrate and stop the domains, within the
-    limits of hypervisor support for these operations.</para>
-
-    <para>The libvirt daemon runs on the Enea NFV Access host. All tools built
-    on libvirt API connect to the daemon to request the desired operation, and
-    to collect information about the configuration and resources of the host
-    system and guests. <literal>virsh</literal> is a command line interface
-    tool for managing guests and the hypervisor. The virsh tool is built on
+    (<literal>libvirtd</literal>) and a command line utility
+    (<literal>virsh</literal>) to manage virtualized environments.</para>
+
+    <para>The <literal>libvirt</literal> library is a hypervisor-independent
+    virtualization API and toolkit that is able to interact with the
+    virtualization capabilities of a range of operating systems.
+    <literal>Libvirt</literal> provides a common, generic and stable layer to
+    securely manage domains on a node. As nodes may be remotely located, it
+    provides all methods required to provision, create, modify, monitor,
+    control, migrate and stop the domains, within the limits of hypervisor
+    support for these operations.</para>
+
+    <para>The <literal>libvirt</literal> daemon runs on the Enea NFV Access
+    host. All tools built upon the libvirt API, connect to the daemon to
+    request the desired operation, and to collect information about the
+    configuration and resources of the host system and guests.
+    <literal>virsh</literal> is a command line interface tool for managing
+    guests and the hypervisor. The <literal>virsh</literal> tool is built upon
     the libvirt management API.</para>
 
     <para><emphasis role="bold">Major functionality provided by
@@ -247,7 +253,7 @@ $ testpmd -c 0x7 -- -i --rxq=2 --txq=2 --nb-cores=2 ...</programlisting>
         <para><emphasis role="bold">VM management:</emphasis> Various domain
         lifecycle operations such as start, stop, pause, save, restore, and
         migrate. Hotplug operations for many device types including disk and
-        network interfaces, memory, and cpus.</para>
+        network interfaces, memory, and CPUs.</para>
       </listitem>
 
       <listitem>
@@ -391,7 +397,8 @@ $ testpmd -c 0x7 -- -i --rxq=2 --txq=2 --nb-cores=2 ...</programlisting>
         <listitem>
           <para>In the <literal>&lt;cputune&gt;</literal> tag it is further
           possible to specify on which CPU the emulator shall run by adding
-          the cpuset to the <literal>&lt;emulatorpin&gt;</literal> tag.</para>
+          the <literal>cpuset</literal> to the
+          <literal>&lt;emulatorpin&gt;</literal> tag.</para>
 
           <programlisting>&lt;vcpu placement='static'&gt;2&lt;/vcpu&gt;
 &lt;cputune&gt;
@@ -401,7 +408,7 @@ $ testpmd -c 0x7 -- -i --rxq=2 --txq=2 --nb-cores=2 ...</programlisting>
 &lt;/cputune&gt;</programlisting>
 
           <para><literal>libvirt</literal> will group all threads belonging to
-          a qemu instance into cgroups that will be created for that purpose.
+          a QEMU instance into cgroups that will be created for that purpose.
           It is possible to supply a base name for those cgroups using the
           <literal>&lt;resource&gt;</literal> tag:</para>
 
@@ -418,8 +425,8 @@ $ testpmd -c 0x7 -- -i --rxq=2 --txq=2 --nb-cores=2 ...</programlisting>
       <para>Command <command>virsh net-create</command> starts a network. If
       any networks are listed in the guest XML file, those networks must be
       started before the guest is started. As an example, if the network is
-      defined in a file named example-net.xml, it is started as
-      follows:</para>
+      defined in a file named <filename>example-net.xml</filename>, it will be
+      started as such:</para>
 
       <programlisting>virsh net-create example-net.xml
 &lt;network&gt;
@@ -448,25 +455,26 @@ $ testpmd -c 0x7 -- -i --rxq=2 --txq=2 --nb-cores=2 ...</programlisting>
 
       <programlisting>virsh net-autostart example-net</programlisting>
 
-      <para>Guest configuration file (xml) must be updated to access newly
-      created network like so:</para>
+      <para>The guest configuration file (xml) must be updated to access the
+      newly created network like so:</para>
 
       <programlisting>    &lt;interface type='network'&gt;
       &lt;source network='sriov'/&gt;
     &lt;/interface&gt;</programlisting>
 
-      <para>The following presented here are a few modes of network access
-      from guest using <command>virsh</command>:</para>
+      <para>The following are a few ways of network access from a guest while
+      using <command>virsh</command>:</para>
 
       <itemizedlist>
         <listitem>
           <para><emphasis role="bold">vhost-user interface</emphasis></para>
 
-          <para>See the Open vSwitch chapter on how to create vhost-user
-          interface using Open vSwitch. Currently there is no Open vSwitch
-          support for networks that are managed by libvirt (e.g. NAT). As of
-          now, only bridged networks are supported (those where the user has
-          to manually create the bridge).</para>
+          <para>See the Open vSwitch chapter on how to create a
+          <literal>vhost-user</literal> interface using Open vSwitch.
+          Currently there is no Open vSwitch support for networks that are
+          managed by <literal>libvirt </literal>(e.g. NAT). Until further
+          notice, only bridged networks are supported (those where the user
+          has to manually create the bridge).</para>
 
           <programlisting>    &lt;qemu:commandline&gt;
       &lt;qemu:arg value='-chardev'/&gt;
@@ -474,7 +482,8 @@ $ testpmd -c 0x7 -- -i --rxq=2 --txq=2 --nb-cores=2 ...</programlisting>
       &lt;qemu:arg value='-netdev'/&gt;
       &lt;qemu:arg value='type=vhost-user,id=hostnet0,chardev=charnet0'/&gt;
       &lt;qemu:arg value='-device'/&gt;
-      &lt;qemu:arg value='virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:00:00:01,bus=pcie.0,addr=0x2'/&gt;
+      &lt;qemu:arg value='virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:00:00:01,/
+      bus=pcie.0,addr=0x2'/&gt;
     &lt;/qemu:commandline&gt;</programlisting>
         </listitem>
 
@@ -492,15 +501,8 @@ $ testpmd -c 0x7 -- -i --rxq=2 --txq=2 --nb-cores=2 ...</programlisting>
 
           <itemizedlist>
             <listitem>
-              <para>Allow unsafe interrupts in case the system doesn't support
-              interrupt remapping. This can be done using
-              <literal>vfio_iommu_type1.allow_unsafe_interrupts=1</literal> as
-              a boot kernel parameter.</para>
-            </listitem>
-
-            <listitem>
               <para>Change the owner of the
-              <literal>/dev/vfio/&lt;group&gt;</literal> to qemu and edit
+              <literal>/dev/vfio/&lt;group&gt;</literal> to QEMU and edit
               <literal>/etc/libvirt/qemu.conf</literal> to explicitly allow
               permission to it:</para>
 
@@ -522,7 +524,7 @@ cgroup_device_acl = [
 
             <listitem>
               <para>Increase the locked memory limits within the libvirtd
-              service file :</para>
+              service file:</para>
 
               <para><programlisting>$ cat /lib/systemd/system/libvirtd.service
 ...
@@ -539,17 +541,19 @@ Restart=on-failure
 #LimitNOFILE=2048
 ...</programlisting></para>
             </listitem>
-          </itemizedlist>
 
-          <para>VFs must be created on the host before starting the
-          guest:</para>
+            <listitem>
+              <para>VFs must be created on the host before starting the
+              guest:</para>
 
-          <programlisting>$ modprobe vfio_pci
+              <programlisting>$ modprobe vfio_pci
 $ dpdk-devbind.py --bind=vfio-pci 0001:01:00.1
    &lt;qemu:commandline&gt;
      &lt;qemu:arg value='-device'/&gt;
      &lt;qemu:arg value='vfio-pci,host=0001:01:00.1'/&gt;
    &lt;/qemu:commandline&gt;</programlisting>
+            </listitem>
+          </itemizedlist>
         </listitem>
 
         <listitem>
@@ -632,7 +636,8 @@ $ dpdk-devbind.py --bind=vfio-pci 0001:01:00.1
      &lt;qemu:arg value='-netdev'/&gt;
      &lt;qemu:arg value='type=vhost-user,id=hostnet0,chardev=charnet0'/&gt;
      &lt;qemu:arg value='-device'/&gt;
-     &lt;qemu:arg value='virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:00:00:01,bus=pcie.0,addr=0x2'/&gt;
+     &lt;qemu:arg value='virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:00:00:01,/
+     bus=pcie.0,addr=0x2'/&gt;
   &lt;/qemu:commandline&gt;
 &lt;/domain&gt;</programlisting>
       </section>
@@ -760,4 +765,4 @@ $ dpdk-devbind.py --bind=vfio-pci 0001:01:00.1
       </section>
     </section>
   </section>
-</chapter>
+</chapter>
\ No newline at end of file
diff --git a/doc/book-enea-nfv-access-guide/doc/overview.xml b/doc/book-enea-nfv-access-guide/doc/overview.xml
index d81087a..238345a 100644
--- a/doc/book-enea-nfv-access-guide/doc/overview.xml
+++ b/doc/book-enea-nfv-access-guide/doc/overview.xml
@@ -1,37 +1,36 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 <chapter id="overview">
   <title>Overview</title>
 
-  <para>The Enea NFV Access Guide available with this release of the Enea NFV
-  Access seeks to provide further information that will help all intended
-  users make the most out of the virtualization features.</para>
+  <para>The Enea NFV Access Guide available with this release seeks to provide
+  further information that will help all intended users make the most out of
+  the virtualization features.</para>
 
   <section id="description">
     <title>Enea NFV Access Description</title>
 
     <para>Enea NFV Access is a lightweight virtualization software designed
-    for deployment on edge devices at customer premises. Streamlined for high
-    networking performance and minimal footprints for both host platform and
-    VNFs, it enables very high compute density.</para>
-
-    <para>Enea NFV Access also provides a foundation for vCPE agility and
-    innovation, reducing cost and complexity for computing at the network
-    edge. It supports multiple architectures and scales from small white box
-    edge devices up to high-end network servers. Thanks to the streamlined
-    footprint, Enea NFV Access can be deployed on systems as small as single
-    2-core ARM devices. It scales up to clustered 24 core OCTEON TX™ ARM
-    Micro-servers and beyond, allowing multiple VNFs on the same machine, and
-    eliminating the need to use different virtualization software for
-    different hardware platforms, saving costs through single source
-    provisioning.</para>
+    for deployment on edge devices at customer premises. It has been
+    streamlined for high networking performance and low footprints for both
+    host platforms and VNFs, enabling high compute density. This software also
+    provides a foundation for vCPE agility and innovation, reducing cost and
+    complexity for computing at the network edge.</para>
+
+    <para>Enea NFV Access supports multiple architectures and scales from
+    small white box edge devices up to high-end network servers. It can also
+    be deployed on systems as small as single 2-core ARM devices. It scales up
+    to clustered 24 core OCTEON TX&trade; ARM Micro-servers and beyond,
+    allowing multiple VNFs on the same machine, and eliminating the need to
+    use different virtualization software for different hardware platforms,
+    saving costs through single source provisioning.</para>
 
     <para>Optimized virtual networking performance provides low virtualized
     networking latency, high virtualized networking throughput (10 Gb wire
     speed), and low processing overhead. It allows high compute density on
     white box hardware, maintaining performance when moving functionality from
-    application specific appliances to software on standard hardware. The
+    application specific appliances, to software on standard hardware. The
     optimized boot speed minimizes the time from reboot to active services,
     improving availability.</para>
 
@@ -39,33 +38,29 @@
     virtual machines. Containers provide lightweight virtualization for a
     smaller VNF footprint and a very short time interval from start to enabled
     network services. VMs provide virtualization with secure VNF sandboxing
-    and is the preferred virtualization method for OPNFV compliance. Enea NFV
-    Access allows combinations of containers and VMs for highest possible user
-    adaptability.</para>
+    and are the preferred virtualization method for OPNFV compliance. Enea NFV
+    Access allows combinations of containers and VMs for the highest possible
+    user adaptability.</para>
 
     <para>Flexible interfaces for VNF lifecycle management and service
-    function chaining, are important to allow a smooth transition from
+    function chaining, are important to allow for a smooth transition from
     traditional network appliances to virtualized network functions in
-    existing networks, as they plug into a variety of interfaces. Enea NFV
-    Access supports VNF lifecycle management and service function chaining
-    through NETCONF, REST, CLI and Docker. It integrates a powerful device
-    management framework that enables full FCAPS functionality for powerful
-    management of the platform.</para>
+    existing networks. Enea NFV Access supports VNF lifecycle management and
+    service function chaining through NETCONF, REST, CLI and Docker. It
+    integrates a powerful device management framework that enables full FCAPS
+    functionality for powerful management of the platform.</para>
 
     <para>Building on open source, Enea NFV Access prevents vendor lock-in
-    thanks to its completely open standards and interfaces. Unlike proprietary
-    platforms that either do not allow decoupling of software from hardware,
-    or prevent NVF portability, Enea NFV Access includes optimized components
-    with open interfaces to allow full portability and
+    thanks to its completely open standards and interfaces. It includes
+    optimized components with open interfaces to allow full portability and
     interoperability.</para>
   </section>
 
   <section id="components">
     <title>Components</title>
 
-    <para>Enea NFV Access is built on highly optimized open source and
-    value-adding components that provide standard interfaces but with boosted
-    performance.</para>
+    <para>Enea NFV Access is built on highly optimized open source components
+    that provide standard interfaces with boosted performance.</para>
 
     <mediaobject>
       <imageobject>
@@ -88,9 +83,8 @@
       </listitem>
 
       <listitem>
-        <para>Docker - Docker provides a lightweight configuration using
-        containers. Docker is the standard platform for container
-        virtualization.</para>
+        <para>Docker - Provides a lightweight configuration using containers.
+        Docker is the standard platform for container virtualization.</para>
       </listitem>
 
       <listitem>
@@ -99,9 +93,8 @@
       </listitem>
 
       <listitem>
-        <para>Edge Link - Edge Link provides interfaces to orchestration for
-        centralized VNF lifecycle management and service function
-        chaining:</para>
+        <para>Edge Link - Provides interfaces to orchestration for centralized
+        VNF lifecycle management and service function chaining:</para>
 
         <orderedlist>
           <listitem>
@@ -129,19 +122,20 @@
       </listitem>
 
       <listitem>
-        <para>CLI based VNF management - CLI access over virsh and
-        libvirt.</para>
+        <para>CLI based VNF management - CLI access over
+        <literal><filename>virsh</filename></literal> and
+        <filename>libvirt</filename>.</para>
       </listitem>
 
       <listitem>
-        <para>FCAPS framework - The device management framework for managing
-        the platform is capable of providing full FCAPS functionality to
+        <para>FCAPS framework - Device management framework for managing the
+        platform, capable of providing full FCAPS functionality to
         orchestration or network management systems.</para>
       </listitem>
 
       <listitem>
-        <para>Data plane - High performance data plane that includes the
-        following optimized data plane DPDK driver.</para>
+        <para>Data plane - High performance data plane that includes the DPDK
+        optimized data plane driver.</para>
       </listitem>
     </itemizedlist>
   </section>
diff --git a/doc/book-enea-nfv-access-guide/doc/ovs.xml b/doc/book-enea-nfv-access-guide/doc/ovs.xml
index fdbd692..de14f76 100644
--- a/doc/book-enea-nfv-access-guide/doc/ovs.xml
+++ b/doc/book-enea-nfv-access-guide/doc/ovs.xml
@@ -97,8 +97,9 @@
   <section id="setup-ovs-dpdk">
     <title>How to set up OVS-DPDK</title>
 
-    <para>The DPDK must be configured prior to setting up OVS-DPDK. See
-     <xref linkend="dpdk-setup"/> for DPDK setup instructions, then follow these steps:</para>
+    <para>The DPDK must be configured prior to setting up OVS-DPDK. See <xref
+    linkend="dpdk-setup" /> for DPDK setup instructions, then follow these
+    steps:</para>
 
     <orderedlist>
       <listitem>
@@ -114,7 +115,7 @@ rm -f /etc/openvswitch/conf.db</programlisting>
 
         <programlisting>export DB_SOCK=/var/run/openvswitch/db.sock
 ovsdb-tool create /etc/openvswitch/conf.db /usr/share/openvswitch/vswitch.ovsschema
-ovsdb-server --remote=punix:$DB_SOCK /
+ovsdb-server --remote=punix:$DB_SOCK \
 --remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach</programlisting>
       </listitem>
 
@@ -125,7 +126,7 @@ ovsdb-server --remote=punix:$DB_SOCK /
 ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-lcore-mask=0x1
 ovs-vsctl --no-wait set Open_vSwitch . other_config:pmd-cpu-mask=0xc
 ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true
-ovs-vswitchd unix:$DB_SOCK --pidfile --detach /
+ovs-vswitchd unix:$DB_SOCK --pidfile --detach \
 --log-file=/var/log/openvswitch/ovs-vswitchd.log</programlisting>
       </listitem>
 
@@ -133,7 +134,7 @@ ovs-vswitchd unix:$DB_SOCK --pidfile --detach /
         <para>Create the OVS bridge and attach ports:</para>
 
         <programlisting>ovs-vsctl add-br ovsbr0 -- set bridge ovsbr0 datapath_type=netdev
-ovs-vsctl add-port ovsbr0 dpdk0 -- set Interface dpdk0 type=dpdk /
+ovs-vsctl add-port ovsbr0 dpdk0 -- set Interface dpdk0 type=dpdk \
 :dpdk-devargs=&lt;PCI device&gt;</programlisting>
       </listitem>
 
@@ -144,8 +145,8 @@ ovs-vsctl add-port ovsbr0 dpdk0 -- set Interface dpdk0 type=dpdk /
 
         <para>This command creates a socket at
         <literal>/var/run/openvswitch/vhost-user1</literal>, which can be
-        provided to the VM on the QEMU command line. See <xref linkend="net_in_guest"/> for
-        details.</para>
+        provided to the VM on the QEMU command line. See <xref
+        linkend="net_in_guest" /> for details.</para>
       </listitem>
 
       <listitem>
diff --git a/doc/book-enea-nfv-access-guide/doc/using_nfv_access_sdks.xml b/doc/book-enea-nfv-access-guide/doc/using_nfv_access_sdks.xml
index e550005..1f7ab8c 100644
--- a/doc/book-enea-nfv-access-guide/doc/using_nfv_access_sdks.xml
+++ b/doc/book-enea-nfv-access-guide/doc/using_nfv_access_sdks.xml
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 <chapter id="workflow">
@@ -184,10 +184,14 @@ MODULE_LICENSE("GPL");</programlisting>
         target and install/remove it:</para>
 
         <programlisting># insmod hello.ko
-# rmmod hello.ko
-</programlisting>
+# rmmod hello.ko</programlisting>
       </listitem>
     </orderedlist>
+
+    <para>If you build a module using the SDK for development image, and
+    insert to the release image you will get error when running
+    <literal>rmmod</literal>: <programlisting>root@cn8304:~# rmmod hello.ko &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; 
+rmmod: ERROR: could not remove module hello.ko: Device or resource busy</programlisting></para>
   </section>
 
   <section id="deploy-artifacts">
@@ -300,11 +304,11 @@ MODULE_LICENSE("GPL");</programlisting>
 
     <itemizedlist>
       <listitem>
-        <para>Kgdb – for kernel cross-debugging</para>
+        <para>Kgdb - for kernel cross-debugging</para>
       </listitem>
 
       <listitem>
-        <para>GDBServer – for application cross-debugging</para>
+        <para>GDBServer - for application cross-debugging</para>
       </listitem>
     </itemizedlist>
 
@@ -448,16 +452,16 @@ ip route add default via 192.168.122.1 dev enp0s2</programlisting></para>
         <listitem>
           <para>On your development machine, start cross-gdb using the vmlinux
           kernel image as a parameter. The image is located in
-          <filename>&lt;sdkdir&gt;/sysroots/corei7-64-enea-linux/boot/</filename>
+          <filename>&lt;sdkdir&gt;/sysroots/aarch64-enea-linux/boot/</filename>
           and should be the same as the image found in the
-          <literal>/boot</literal> directory from the target.<programlisting>$ aarch64-enea-linux-gdb /
+          <literal>/boot</literal> directory from the target:<programlisting>$ aarch64-enea-linux-gdb \
     ./sysroots/aarch64-enea-linux/boot/ \
      vmlinux-4.9.0-octeontx.sdk.6.1.0.p3.build.22-cavium-tiny</programlisting></para>
         </listitem>
 
         <listitem>
-          <para>Connect GDB to the target machine using target command and the
-          serial device:<programlisting>(gdb) set remotebaud 115200
+          <para>Connect GDB to the target machine using the target command and
+          the serial device:<programlisting>(gdb) set remotebaud 115200
 (gdb) target remote /dev/ttyS0</programlisting></para>
         </listitem>
       </itemizedlist>