Ubuntu Server Guide Changes, errors and bugs

103

Virtual functions are usually assigned via their PCI-ID (domain, bus, slot, function).





Note
To get the Virtual function in the first place is very device dependent and can therefore not be
fully covered here. But in general it involves setting up an iommu, registering via VFIO and
sometimes requesting a number of VFs. Here an example on ppc64el to get 4 VFs on a device:
$ sudo modprobe v f i o −p c i
# i d e n t i f y d e v i c e
$ l s p c i −n −s 0 0 0 5 : 0 1 : 0 1 . 3
0 0 0 5 : 0 1 : 0 1 . 3 0 2 0 0 : 10 d f : e228 ( r e v 1 0 )
# r e g i s t e r and r e q u e s t VFs
$ echo 10 d f e228 | sudo t e e / s y s / bus / p c i / d r i v e r s / v f i o −p c i /new_id
$ echo 4 | sudo t e e / s y s / bus / p c i / d e v i c e s / 0 0 0 5 \ : 0 1 \ : 0 0 . 0 / sriov_numvfs
You then attach or detach the device via libvirt by relating the guest with the xml snippet.
v i r s h a t t a c h −d e v i c e  
# Use t h e De v i ce i n t t h e Guest
v i r s h detach−d e v i c e  
Access Qemu Monitor via libvirt
The Qemu Monitor is the way to interact with qemu/KVM while a guest is running. This interface has
many and very powerful features for experienced users. When running under libvirt that monitor interface
is bound by libvirt itself for management purposes, but a user can run qemu monitor commands via libvirt
still. The general syntax is virsh qemu−monitor−command [options] [guest] ’command’
Libvirt covers most use cases needed, but if you every want/need to work around libvirt or want to tweak
very special options you can e.g. add a device that way:
v i r s h qemu−monitor−command −−hmp f o c a l −t e s t −l o g ’ drive_add 0 i f =none , f i l e =/var
/ l i b / l i b v i r t / images / t e s t . img , format=raw , i d=d i s k 1 ’
But since the monitor is so powerful, you can do a lot especially for debugging purposes like showing the
guest registers:
v i r s h qemu−monitor−command −−hmp y−i p n s ’ i n f o r e g i s t e r s ’
RAX=00 f f f f c 0 0 0 0 0 0 0 0 0 RBX=f f f f 8 f 0 f 5 d 5 c 7 e 4 8 RCX=0000000000000000 RDX=
f f f f e a 0 0 0 0 7 5 7 1 c 0
RSI =0000000000000000 RDI=f f f f 8 f 0 f d d 5 c 7 e 4 8 RBP=f f f f 8 f 0 f 5 d 5 c 7 e 1 8 RSP=
f f f f 8 f 0 f 5 d 5 c 7 d f 8
[ . . . ]
104

Huge Pages
Using huge pages can help to reduce TLB pressure, page table overhead and speed up some further memory
relate actions. Furthermore by default Transparent huge pages are useful, but can be quite some overhead -
so if it is clear that using huge pages is preferred making them explicit usually has some gains.
While huge page are admittedly harder to manage, especially later in the lifetime of a system if memory is
fragmented they provide a useful boost especially for rather large guests.
Bonus: When using device pass through on very large guests there is an extra benefit of using huge pages
as it is faster to do the initial memory clear on vfio dma pin.
Huge page allocation
Huge pages come in different sizes. A normal page usually is 4k and huge pages are eithe 2M or 1G, but
depending on the architecture other options are possible.
The most simple, yet least reliable way to allocate some huge pages is to just echo a value to sysfs Be sure
to re-check if it worked.
$ echo 256 | sudo t e e / s y s / k e r n e l /mm/ hugepages / hugepages −2048kB/ nr_hugepages
$ c a t / s y s / k e r n e l /mm/ hugepages / hugepages −2048kB/ nr_hugepages
256
There one of these sizes is “default huge page size” which will be used in the auto-mounted /dev/hugepages.
Changing the default size requires a reboot and is set via default_hugepagesz
You can check the current default size:
$ g r e p H u g e p a g e s i z e / p r o c / meminfo
H u g e p a g e s i z e :
2048 kB
But there can be more than one at the same time one better check:
$ t a i l / s y s / k e r n e l /mm/ hugepages / hugepages −*/nr_hugepages ‘
==> / s y s / k e r n e l /mm/ hugepages / hugepages −1048576kB/ nr_hugepages <==
0
==> / s y s / k e r n e l /mm/ hugepages / hugepages −2048kB/ nr_hugepages <==
2
And even that could on bigger systems be further split per Numa node.
One can allocate huge pages at boot or runtime, but due to fragmentation there are no guarantees it works
later. The kernel documentation lists details on both ways.
Huge pages need to be allocated by the kernel as mentioned above but to be consumable they also have to
be mounted. By default systemd will make /dev/hugepages available for the default huge page size. Feel
free to add more mount points if you need different sized. An overview can be queried with
$ hugeadm −− l i s t −a l l −mounts
Mount Po int
Options
/ dev / hugepages
rw , r e l a t i m e , p a g e s i z e =2M
A one-stop info for the overall huge page status of the system can be reported with
$ hugeadm −−e x p l a i n
105

Huge page usage in libvirt
With the above in place libvirt can map guest memory to huge pages. In a guest definition add the most
simple form of