February 2019 - Devel - libvirt List Archives

[libvirt] [python PATCH] Fix virDomainPinIOThread typed params check
by Pavel Hrdina 25 Feb '19

25 Feb '19

The VIR_DOMAIN_IOTHREAD_POLL_SHRINK is unsigned int. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1680546 Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- Pushed under trivial rule. libvirt-override.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libvirt-override.c b/libvirt-override.c index f7b2f6b..857c018 100644 --- a/libvirt-override.c +++ b/libvirt-override.c @@ -1684,7 +1684,7 @@ libvirt_virDomainPinIOThread(PyObject *self ATTRIBUTE_UNUSED, static virPyTypedParamsHint virPyDomainSetIOThreadParams[] = { { VIR_DOMAIN_IOTHREAD_POLL_MAX_NS, VIR_TYPED_PARAM_ULLONG }, { VIR_DOMAIN_IOTHREAD_POLL_GROW, VIR_TYPED_PARAM_UINT }, - { VIR_DOMAIN_IOTHREAD_POLL_SHRINK, VIR_TYPED_PARAM_ULLONG }, + { VIR_DOMAIN_IOTHREAD_POLL_SHRINK, VIR_TYPED_PARAM_UINT }, }; static PyObject * -- 2.20.1

1 0

[libvirt] [libvirt-go PATCH 0/3] Introduce recent DomainSnapshotXML and DomainSaveImageXML flags
by Erik Skultety 25 Feb '19

25 Feb '19

Unfortunately, in order to support the new flags, the last patch introduces an API breakage as the convention we use for the bindings is to also enforce types for flags. Erik Skultety (3): Introduce DomainSnapshotXMLFlags constant Introduce DomainSaveImageXMLFlags constant Enforce new flags types in DomainSaveImageGetXMLDesc and GetXMLDesc connect.go | 2 +- domain.go | 8 +++++++- domain_compat.h | 8 ++++++++ domain_snapshot.go | 8 +++++++- domain_snapshot_wrapper.h | 2 +- 5 files changed, 24 insertions(+), 4 deletions(-) -- 2.20.1

3 13

[libvirt] [PATCH 0/2] further apparmor handling of opengl
by Christian Ehrhardt 25 Feb '19

25 Feb '19

Further testing with opengl enabled graphics showed that we need much more rules than we initially added. Upstream apparmor has abstractions [1][2] for the majority of what we'd need, but those are in no Distribution yet so we can't rely on them. But we can add rules "like those known ones" matching what our testing shows as needed when we add a gl enabled device. There is no overly critical access opened by this, but still we continue to only add those to the guests that have gl enabled. The most "discussion worthy" part of it most likely are the wildcards into /dev/devices/... but they are rather specific and read only - furthermore retracing those in advance starting from the rendernode most likely is rather error prone, so I went with the wildcards. Example apparmor denials can be found in the launchpad bug [3] [1]: https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/abstra… [2]: https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/abstra… [3]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452 Christian Ehrhardt (2): security: aa-helper: allow virt-aa-helper to read /dev/dri security: aa-helper: generate more rules for gl devices .../apparmor/usr.lib.libvirt.virt-aa-helper | 3 +++ src/security/virt-aa-helper.c | 20 ++++++++++++++++++- 2 files changed, 22 insertions(+), 1 deletion(-) -- 2.17.1

2 11

[libvirt] [PATCH v2 0/3] bhyve: implement MSRs ignore unknown writes feature
by Roman Bogorodskiy 24 Feb '19

24 Feb '19

Changes from v1: * Replaced <msrs ignoreUnknownWrites='yes'/> with <msrs unknown="ignore|fault"/> Roman Bogorodskiy (3): conf: introduce 'msrs' feature bhyve: implement ignore unknown MSRs feature news: document bhyve msrs feature docs/drvbhyve.html.in | 22 +++++++++++ docs/formatdomain.html.in | 1 + docs/news.xml | 10 +++++ docs/schemas/domaincommon.rng | 14 +++++++ src/bhyve/bhyve_command.c | 4 ++ src/conf/domain_conf.c | 38 +++++++++++++++++++ src/conf/domain_conf.h | 16 ++++++++ src/qemu/qemu_domain.c | 1 + .../bhyvexml2argvdata/bhyvexml2argv-msrs.args | 10 +++++ .../bhyvexml2argv-msrs.ldargs | 3 ++ .../bhyvexml2argvdata/bhyvexml2argv-msrs.xml | 26 +++++++++++++ tests/bhyvexml2argvtest.c | 1 + .../bhyvexml2xmlout-msrs.xml | 36 ++++++++++++++++++ tests/bhyvexml2xmltest.c | 1 + 14 files changed, 183 insertions(+) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-msrs.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-msrs.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-msrs.xml create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-msrs.xml -- 2.20.1

2 7

[libvirt] [PATCH 0/2] cputest: Update python scripts for parsing CPU data
by Jiri Denemark 22 Feb '19

22 Feb '19

Jiri Denemark (2): cputest: Adapt scripts to split cpu_map cputest: Use python3 in CPU parser scripts tests/cputestdata/cpu-cpuid.py | 24 +++++++++++------------- tests/cputestdata/cpu-reformat.py | 2 +- 2 files changed, 12 insertions(+), 14 deletions(-) -- 2.20.1

2 3

[libvirt] [PATCH] nwfilter: allow for different format of IPv6 netmask/prefix in ebtables output
by Laine Stump 22 Feb '19

22 Feb '19

The iptables-ebtables package is meant as a drop-in replacement for the native ebtables package, but it formats some items in the -L output differently, leading to failure of scripts that depend on the output of ebtables -L. In particular: with old ebtables IPv6 prefixes are output as a netmask (e.g.: "/ffff:fc00") with iptables-ebtables IPv6 prefixes are always output as a numeric prefix (e.g. "/22"), and suppressed completely if the prefix is /128. This difference is also described in https://bugzilla.redhat.com/show_bug.cgi?id=1674536 "old" ebtables upstream has just accepted a patch to change its output to match that of iptables-ebtables: https://marc.info/?l=netfilter-devel&m=155000828923204&w=2 so it makes sense for libvirt-tck to accept the new format (as well as the old). As with the patch for fixing up MAC addresses with leading 0s, this patch also uses sed to apply a substitution to the scraped output of ebtables -L. However, rather than keeping the comparison (expected) output in the old (netmask) form, it is changed to the new (prefix) form, and the sed commands change netmasks to prefixes. (This works out better because in some cases we need to replace [all ff's] with "", and it's not possible to do that in the opposite direction :-) Signed-off-by: Laine Stump <laine(a)laine.org> --- NB: ebtables upstream hasn't changed the format of MAC addresses (yet). Also, some new errors have cropped up when running these same tests on RHEL8, but I think they are due to some new "real" bug in iptables-ebtables, since the xml2fwallout tests all succeed when run individually. .../nwfilterxml2fwallout/comment-test.fwall | 4 ++-- .../nwfilterxml2fwallout/hex-data-test.fwall | 4 ++-- .../nwfilterxml2fwallout/ipv6-test.fwall | 18 +++++++++--------- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/scripts/nwfilter/nwfilterxml2fwallout/comment-test.fwall b/scripts/nwfilter/nwfilterxml2fwallout/comment-test.fwall index d87843b..4f467bf 100644 --- a/scripts/nwfilter/nwfilterxml2fwallout/comment-test.fwall +++ b/scripts/nwfilter/nwfilterxml2fwallout/comment-test.fwall @@ -2,9 +2,9 @@ -i vnet0 -j libvirt-I-vnet0 #ebtables -t nat -L POSTROUTING | grep vnet0 | grep -v "^Bridge" | grep -v "^$" -o vnet0 -j libvirt-O-vnet0 -#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | sed s/0a:0b:0c:0d:0e:0f/a:b:c:d:e:f/g | grep -v "^Bridge" | grep -v "^$" +#ebtables -t nat -L libvirt-I-vnet0 | sed 's#/ffff:ffff:ffff:ffff:ffff:ffff:ffff:8000#/113#g' | sed 's#/ffff:fc00::#/22#g' | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | sed s/0a:0b:0c:0d:0e:0f/a:b:c:d:e:f/g | grep -v "^Bridge" | grep -v "^$" -p IPv4 -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --ip-src 10.1.2.3 --ip-dst 10.1.2.3 --ip-tos 0x32 --ip-proto udp --ip-sport 291:564 --ip-dport 13398:17767 -j ACCEPT --p IPv6 -s 1:2:3:4:5:6/ff:ff:ff:ff:ff:fe -d aa:bb:cc:dd:ee:80/ff:ff:ff:ff:ff:80 --ip6-src ::/ffff:fc00:: --ip6-dst ::10.1.0.0/ffff:ffff:ffff:ffff:ffff:ffff:ffff:8000 --ip6-proto tcp --ip6-sport 273:400 --ip6-dport 13107:65535 -j ACCEPT +-p IPv6 -s 1:2:3:4:5:6/ff:ff:ff:ff:ff:fe -d aa:bb:cc:dd:ee:80/ff:ff:ff:ff:ff:80 --ip6-src ::/22 --ip6-dst ::10.1.0.0/113 --ip6-proto tcp --ip6-sport 273:400 --ip6-dport 13107:65535 -j ACCEPT -p ARP -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --arp-op Request --arp-htype 18 --arp-ptype 0x56 --arp-mac-src 1:2:3:4:5:6 --arp-mac-dst a:b:c:d:e:f -j ACCEPT #ebtables -t nat -L libvirt-O-vnet0 | grep -v "^Bridge" | grep -v "^$" -p 0x1234 -j ACCEPT diff --git a/scripts/nwfilter/nwfilterxml2fwallout/hex-data-test.fwall b/scripts/nwfilter/nwfilterxml2fwallout/hex-data-test.fwall index 56d3956..0cd9a8d 100644 --- a/scripts/nwfilter/nwfilterxml2fwallout/hex-data-test.fwall +++ b/scripts/nwfilter/nwfilterxml2fwallout/hex-data-test.fwall @@ -2,9 +2,9 @@ -i vnet0 -j libvirt-I-vnet0 #ebtables -t nat -L POSTROUTING | grep vnet0 | grep -v "^Bridge" | grep -v "^$" -o vnet0 -j libvirt-O-vnet0 -#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | sed s/0a:0b:0c:0d:0e:0f/a:b:c:d:e:f/g | grep -v "^Bridge" | grep -v "^$" +#ebtables -t nat -L libvirt-I-vnet0 | sed 's#/ffff:ffff:ffff:ffff:ffff:ffff:ffff:8000#/113#g' | sed 's#/ffff:fc00::#/22#g' | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | sed s/0a:0b:0c:0d:0e:0f/a:b:c:d:e:f/g | grep -v "^Bridge" | grep -v "^$" -p IPv4 -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --ip-src 10.1.2.3 --ip-dst 10.1.2.3 --ip-tos 0x32 --ip-proto udp --ip-sport 291:564 --ip-dport 13398:17767 -j ACCEPT --p IPv6 -s 1:2:3:4:5:6/ff:ff:ff:ff:ff:fe -d aa:bb:cc:dd:ee:80/ff:ff:ff:ff:ff:80 --ip6-src ::/ffff:fc00:: --ip6-dst ::10.1.0.0/ffff:ffff:ffff:ffff:ffff:ffff:ffff:8000 --ip6-proto tcp --ip6-sport 273:400 --ip6-dport 13107:65535 -j ACCEPT +-p IPv6 -s 1:2:3:4:5:6/ff:ff:ff:ff:ff:fe -d aa:bb:cc:dd:ee:80/ff:ff:ff:ff:ff:80 --ip6-src ::/22 --ip6-dst ::10.1.0.0/113 --ip6-proto tcp --ip6-sport 273:400 --ip6-dport 13107:65535 -j ACCEPT -p ARP -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --arp-op Request --arp-htype 18 --arp-ptype 0x56 --arp-mac-src 1:2:3:4:5:6 --arp-mac-dst a:b:c:d:e:f -j ACCEPT #ebtables -t nat -L libvirt-O-vnet0 | grep -v "^Bridge" | grep -v "^$" -p 0x1234 -j ACCEPT diff --git a/scripts/nwfilter/nwfilterxml2fwallout/ipv6-test.fwall b/scripts/nwfilter/nwfilterxml2fwallout/ipv6-test.fwall index 7d42f9a..d4dc627 100644 --- a/scripts/nwfilter/nwfilterxml2fwallout/ipv6-test.fwall +++ b/scripts/nwfilter/nwfilterxml2fwallout/ipv6-test.fwall @@ -2,12 +2,12 @@ -i vnet0 -j libvirt-I-vnet0 #ebtables -t nat -L POSTROUTING | grep vnet0 -o vnet0 -j libvirt-O-vnet0 -#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v "^Bridge" | grep -v "^$" --p IPv6 -s 1:2:3:4:5:6/ff:ff:ff:ff:ff:fe -d aa:bb:cc:dd:ee:80/ff:ff:ff:ff:ff:80 --ip6-src ::/ffff:fc00:: --ip6-dst ::10.1.0.0/ffff:ffff:ffff:ffff:ffff:ffff:ffff:8000 --ip6-proto udp --ip6-sport 20:22 --ip6-dport 100:101 -j ACCEPT --p IPv6 --ip6-src a:b:c::/ffff:ffff:ffff:ffff:8000:: --ip6-dst 1::2/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff --ip6-proto tcp --ip6-sport 100:101 --ip6-dport 20:22 -j ACCEPT --p IPv6 --ip6-src a:b:c::/ffff:ffff:ffff:ffff:8000:: --ip6-dst 1::2/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff --ip6-proto tcp --ip6-sport 65535 --ip6-dport 255:256 -j ACCEPT --p IPv6 --ip6-src a:b:c::/ffff:ffff:ffff:ffff:8000:: --ip6-dst 1::2/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff --ip6-proto mux -j ACCEPT -#ebtables -t nat -L libvirt-O-vnet0 | grep -v "^Bridge" | grep -v "^$" --p IPv6 --ip6-src 1::2/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff --ip6-dst a:b:c::/ffff:ffff:ffff:ffff:8000:: --ip6-proto tcp --ip6-sport 20:22 --ip6-dport 100:101 -j ACCEPT --p IPv6 --ip6-src 1::2/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff --ip6-dst a:b:c::/ffff:ffff:ffff:ffff:8000:: --ip6-proto tcp --ip6-sport 255:256 --ip6-dport 65535 -j ACCEPT --p IPv6 --ip6-src 1::2/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff --ip6-dst a:b:c::/ffff:ffff:ffff:ffff:8000:: --ip6-proto mux -j ACCEPT +#ebtables -t nat -L libvirt-I-vnet0 | sed 's#/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff##g' | sed 's#/ffff:ffff:ffff:ffff:ffff:ffff:ffff:8000#/113#g' | sed 's#/ffff:ffff:ffff:ffff:8000::#/65#g' | sed 's#/ffff:fc00::#/22#g' | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v "^Bridge" | grep -v "^$" +-p IPv6 -s 1:2:3:4:5:6/ff:ff:ff:ff:ff:fe -d aa:bb:cc:dd:ee:80/ff:ff:ff:ff:ff:80 --ip6-src ::/22 --ip6-dst ::10.1.0.0/113 --ip6-proto udp --ip6-sport 20:22 --ip6-dport 100:101 -j ACCEPT +-p IPv6 --ip6-src a:b:c::/65 --ip6-dst 1::2 --ip6-proto tcp --ip6-sport 100:101 --ip6-dport 20:22 -j ACCEPT +-p IPv6 --ip6-src a:b:c::/65 --ip6-dst 1::2 --ip6-proto tcp --ip6-sport 65535 --ip6-dport 255:256 -j ACCEPT +-p IPv6 --ip6-src a:b:c::/65 --ip6-dst 1::2 --ip6-proto mux -j ACCEPT +#ebtables -t nat -L libvirt-O-vnet0 | sed 's#/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff##g' | sed 's#/ffff:ffff:ffff:ffff:8000::#/65#g' | grep -v "^Bridge" | grep -v "^$" +-p IPv6 --ip6-src 1::2 --ip6-dst a:b:c::/65 --ip6-proto tcp --ip6-sport 20:22 --ip6-dport 100:101 -j ACCEPT +-p IPv6 --ip6-src 1::2 --ip6-dst a:b:c::/65 --ip6-proto tcp --ip6-sport 255:256 --ip6-dport 65535 -j ACCEPT +-p IPv6 --ip6-src 1::2 --ip6-dst a:b:c::/65 --ip6-proto mux -j ACCEPT -- 2.20.1

2 3

[libvirt] [PATCH v5 03/14] audio: -audiodev command line option: documentation
by Kővágó, Zoltán 22 Feb '19

22 Feb '19

This patch adds documentation of an -audiodev command line option, that deprecates the old QEMU_* environment variables for audio backend configuration. It's syntax is similar to existing options (-netdev, -device, etc): -audiodev driver_name,property=value,... Although now it's possible to specify multiple -audiodev options on command line, multiple audio backends are not supported yet. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu(a)gmail.com> --- Notes: Changes from v4: * deprecated QEMU_AUDIO_ env vars * updated to reflect qapi changes * added info to qemu-deprecated.texi qemu-deprecated.texi | 7 ++ qemu-options.hx | 236 ++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 240 insertions(+), 3 deletions(-) diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 45c57952da..5c07ad4acb 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -60,6 +60,13 @@ Support for invalid topologies will be removed, the user must ensure topologies described with -smp include all possible cpus, i.e. @math{@var{sockets} * @var{cores} * @var{threads} = @var{maxcpus}}. +@subsection QEMU_AUDIO_ environment variables and -audio-help (since 4.0) + +The ``-audiodev'' argument is now the preferred way to specify audio +backend settings instead of environment variables. To ease migration to +the new format, the ``-audiodev-help'' option can be used to convert +the current values of the environment variables to ``-audiodev'' options. + @section QEMU Machine Protocol (QMP) commands @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0) diff --git a/qemu-options.hx b/qemu-options.hx index 77bd98e20b..f77f4d89a7 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -416,14 +416,244 @@ The default is @code{en-us}. ETEXI +HXCOMM Deprecated by -audiodev DEF("audio-help", 0, QEMU_OPTION_audio_help, - "-audio-help print list of audio drivers and their options\n", + "-audio-help show -audiodev equivalent of the currently specified audio settings\n", QEMU_ARCH_ALL) STEXI @item -audio-help @findex -audio-help -Will show the audio subsystem help: list of drivers, tunable -parameters. +Will show the -audiodev equivalent of the currently specified +(deprecated) environment variables. +ETEXI + +DEF("audiodev", HAS_ARG, QEMU_OPTION_audiodev, + "-audiodev [driver=]driver,id=id[,prop[=value][,...]]\n" + " specifies the audio backend to use\n" + " id= identifier of the backend\n" + " timer-period= timer period in microseconds\n" + " in|out.fixed-settings= use fixed settings for host audio\n" + " in|out.frequency= frequency to use with fixed settings\n" + " in|out.channels= number of channels to use with fixed settings\n" + " in|out.format= sample format to use with fixed settings\n" + " valid values: s8, s16, s32, u8, u16, u32\n" + " in|out.voices= number of voices to use\n" + " in|out.buffer-len= length of buffer in microseconds\n" + "-audiodev none,id=id,[,prop[=value][,...]]\n" + " dummy driver that discards all output\n" +#ifdef CONFIG_ALSA + "-audiodev alsa,id=id[,prop[=value][,...]]\n" + " in|out.dev= name of the audio device to use\n" + " in|out.period-len= length of period in microseconds\n" + " in|out.try-poll= attempt to use poll mode\n" + " threshold= threshold (in microseconds) when playback starts\n" +#endif +#ifdef CONFIG_COREAUDIO + "-audiodev coreaudio,id=id[,prop[=value][,...]]\n" + " in|out.buffer-count= number of buffers\n" +#endif +#ifdef CONFIG_DSOUND + "-audiodev dsound,id=id[,prop[=value][,...]]\n" + " latency= add extra latency to playback in microseconds\n" +#endif +#ifdef CONFIG_OSS + "-audiodev oss,id=id[,prop[=value][,...]]\n" + " in|out.dev= path of the audio device to use\n" + " in|out.buffer-count= number of buffers\n" + " in|out.try-poll= attempt to use poll mode\n" + " try-mmap= try using memory mapped access\n" + " exclusive= open device in exclusive mode\n" + " dsp-policy= set timing policy (0..10), -1 to use fragment mode\n" +#endif +#ifdef CONFIG_PA + "-audiodev pa,id=id[,prop[=value][,...]]\n" + " server= PulseAudio server address\n" + " in|out.name= source/sink device name\n" +#endif +#ifdef CONFIG_SDL + "-audiodev sdl,id=id[,prop[=value][,...]]\n" +#endif +#ifdef CONFIG_SPICE + "-audiodev spice,id=id[,prop[=value][,...]]\n" +#endif + "-audiodev wav,id=id[,prop[=value][,...]]\n" + " path= path of wav file to record\n", + QEMU_ARCH_ALL) +STEXI +@item -audiodev [driver=]@var{driver},id=@var{id}[,@var{prop}[=@var{value}][,...]] +@findex -audiodev +Adds a new audio backend @var{driver} identified by @var{id}. There are +global and driver specific properties. Some values can be set +differently for input and output, they're marked with @code{in|out.}. +You can set the input's property with @code{in.@var{prop}} and the +output's property with @code{out.@var{prop}}. For example: +@example +-audiodev alsa,id=example,in.frequency=44110,out.frequency=8000 +-audiodev alsa,id=example,out.channels=1 # leaves in.channels unspecified +@end example + +Valid global options are: + +@table @option +@item id=@var{identifier} +Identifies the audio backend. + +@item timer-period=@var{period} +Sets the timer @var{period} used by the audio subsystem in microseconds. +Default is 10000 (10 ms). + +@item in|out.fixed-settings=on|off +Use fixed settings for host audio. When off, it will change based on +how the guest opens the sound card. In this case you must not specify +@var{frequency}, @var{channels} or @var{format}. Default is on. + +@item in|out.frequency=@var{frequency} +Specify the @var{frequency} to use when using @var{fixed-settings}. +Default is 44100Hz. + +@item in|out.channels=@var{channels} +Specify the number of @var{channels} to use when using +@var{fixed-settings}. Default is 2 (stereo). + +@item in|out.format=@var{format} +Specify the sample @var{format} to use when using @var{fixed-settings}. +Valid values are: @code{s8}, @code{s16}, @code{s32}, @code{u8}, +@code{u16}, @code{u32}. Default is @code{s16}. + +@item in|out.voices=@var{voices} +Specify the number of @var{voices} to use. Default is 1. + +@item in|out.buffer=@var{usecs} +Sets the size of the buffer in microseconds. + +@end table + +@item -audiodev none,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a dummy backend that discards all outputs. This backend has no +backend specific properties. + +@item -audiodev alsa,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates backend using the ALSA. This backend is only available on +Linux. + +ALSA specific options are: + +@table @option + +@item in|out.dev=@var{device} +Specify the ALSA @var{device} to use for input and/or output. Default +is @code{default}. + +@item in|out.period-len=@var{usecs} +Sets the period length in microseconds. + +@item in|out.try-poll=on|off +Attempt to use poll mode with the device. Default is on. + +@item threshold=@var{threshold} +Threshold (in microseconds) when playback starts. Default is 0. + +@end table + +@item -audiodev coreaudio,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend using Apple's Core Audio. This backend is only +available on Mac OS and only supports playback. + +Core Audio specific options are: + +@table @option + +@item in|out.buffer-count=@var{count} +Sets the @var{count} of the buffers. + +@end table + +@item -audiodev dsound,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend using Microsoft's DirectSound. This backend is only +available on Windows and only supports playback. + +DirectSound specific options are: + +@table @option + +@item latency=@var{usecs} +Add extra @var{usecs} microseconds latency to playback. Default is +10000 (10 ms). + +@end table + +@item -audiodev oss,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend using OSS. This backend is available on most +Unix-like systems. + +OSS specific options are: + +@table @option + +@item in|out.dev=@var{device} +Specify the file name of the OSS @var{device} to use. Default is +@code{/dev/dsp}. + +@item in|out.buffer-count=@var{count} +Sets the @var{count} of the buffers. + +@item in|out.try-poll=on|of +Attempt to use poll mode with the device. Default is on. + +@item try-mmap=on|off +Try using memory mapped device access. Default is off. + +@item exclusive=on|off +Open the device in exclusive mode (vmix won't work in this case). +Default is off. + +@item dsp-policy=@var{policy} +Sets the timing policy (between 0 and 10, where smaller number means +smaller latency but higher CPU usage). Use -1 to use buffer sizes +specified by @code{buffer} and @code{buffer-count}. This option is +ignored if you do not have OSS 4. Default is 5. + +@end table + +@item -audiodev pa,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend using PulseAudio. This backend is available on most +systems. + +PulseAudio specific options are: + +@table @option + +@item server=@var{server} +Sets the PulseAudio @var{server} to connect to. + +@item in|out.name=@var{sink} +Use the specified source/sink for recording/playback. + +@end table + +@item -audiodev sdl,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend using SDL. This backend is available on most systems, +but you should use your platform's native backend if possible. This +backend has no backend specific properties. + +@item -audiodev spice,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend that sends audio through SPICE. This backend requires +@code{-spice} and automatically selected in that case, so usually you +can ignore this option. This backend has no backend specific +properties. + +@item -audiodev wav,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend that writes audio to a WAV file. + +Backend specific options are: + +@table @option + +@item path=@var{path} +Write recorded audio into the specified file. Default is +(a)code{qemu.wav}. + +@end table ETEXI DEF("soundhw", HAS_ARG, QEMU_OPTION_soundhw, -- 2.20.1

4 4

[libvirt] QEMU Acceleration with Hypervisor.framework
by Clement BLAISE 22 Feb '19

22 Feb '19

Hello, I’m interested in using hvf also know as Hypervisor. framework acceleration with QEMU which has been supported since 2.12. I’ve gone through the documentation and the code base, I was unable to find an element that could enable it in libvirt. I have come across a patch (link <https://www.spinics.net/linux/fedora/libvir/msg175338.html>) which target this particular feature, but I could not find it in the repo so I guess it has not been applied. Is something that will be supported in the future?

2 1

[libvirt] Configuring pflash devices for OVMF firmware
by Markus Armbruster 22 Feb '19

22 Feb '19

We configure OVMF firmware for PC machine types with -drive if=pflash. This is pretty much the last remaining use of -drive in libvirt we can't yet replace by -blockdev. Such a replacement is desirable, because -blockdev + -device is more flexible than -drive if=pflash. Also, once we don't need -drive with new QEMU anymore, the path for deleting all -drive code in libvirt some day is open. As with all desirables, the benefit needs to exceed the cost. I'm going to describe the status quo, how we got there (briefly and much simplified), then sketch how to replace -drive if=pflash. I'm afraid this is fairly long; sorry. Please correct misunderstandings. Beware, my libvirt and OVMF fu is much weaker than my QEMU fu. In the beginning, board code read the BIOS from a fixed file and mapped it into the guest's address space. Life was simple. On physical hardware, the BIOS can persist a bit of state across (cold) reboots by storing it in (non-volatile) CMOS RAM. We didn't bother. Simple. Fast forward several years, and The Law of OS Envy (every program wants to grow into a full-blown operating system) has asserted itself: PC Firmware has grown from an 8KiB ROM using a few bytes of volatile and non-volatile RAM into a multi-megabyte beast with much more complex storage needs. On today's physical PC hardware, firmware is stored in flash memory. There's code, and there's persistent data. For obvious reasons, the code should be write-protected except when doing an upgrade. "Secure boot" additionally needs to restrict data writes to system management mode (SMM). Here's our first iteration of OVMF support, at QEMU level: -drive if=pflash,format=raw,file=/where/ever/OVMF.fd Generic code creates a block backend for it. Magic board code picks up the backend, creates a frontend (a cfi.pflash01 device), and maps it into the guest's address space. At libvirt level: <loader type="pflash">/where/ever/OVMF.fd</loader> Problem: while the flash device model provides read-only capability, it's all-or-nothing. You can't tell it to write-protect just the part holding code. The examples above don't write-protect anything. /where/ever/OVMF.fd better be writable exclusively. The flash device model could be enhanced, but we went down a different path: we split the single OVMF image OVMF.fd ("unified build") into a code image OVMF_CODE.fd and a data image OVMF_VARS.fd ("split build"). At QEMU level: -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=/where/ever/OVMF_VARS.fd OVMF_CODE.fd must be unit 0, and OVMF_VARS.fd must be unit 1. Generic code creates two block backends. Magic board code picks them up, creates a frontend (a cfi.pflash01 device) for each, and maps them into the guest's address space. Note there are *two* virtual flash devices now, whereas physical hardware commonly has just one. At libvirt level: <loader type="pflash" readonly="yes">/usr/share/OVMF/OVMF_CODE.fd</loader> <nvram template="/usr/share/OVMF/OVMF_VARS.fd">/var/libvirt/nvram/${guest}_VARS.fd</nvram> This treats OVMF_VARS.fd as a read-only template, and gives each guest its own writable copy, which is nice. The flash device model supports restricting writes to SMM (remember, that's required for secure boot). It's controlled by cfi.pflash01 property secure, off by default. If we created the device model with -device, we'd simply pass secure=on. But since we create it with -drive if=pflash, we can't. Instead we have to use -global driver=cfi.pflash01,property=secure,value=on This flips the global default value. Awkward, but works out okay, because (1) the flash device holding OVMF_VARS.fd wants this value, and (2) the flash device holding OVMF_CODE.fd doesn't care (it's read-only), and (3) there is no way to create additional flash devices. At the libvirt level, we add secure='yes' to the loader element. We also have to enable SMM emulation. At QEMU level: -machine smm=on At libvirt level: <features> <smm state='on'/> </features> Note that the above configuration examples involve selecting OVMF images. A bit of an inconvenience compared to BIOS, where the default "use the BIOS shipped with QEMU" pretty much just works. To add annoyance to inconvenience, different distributions have different ideas on where to install OVMF images. And because that's not complicated enough, we also have to pair code with data images. And because that's still not complicated enough, any specific machine type may work only with a subset of the available firmwares. The proposed way to deal with all that works as follows. Each set of firmware images comes with a descriptor file. These are JSON and conform to the QAPI schema docs/interop/firmware.json. Among the descriptors that declare support for the kind of machine we want, we pick (really: the management application picks) the one with the highest priority. The distribution provides default priorities, which system administrator and user can override. firmware.json documents this in much more detail. I wrote "proposed", because as far as I can tell, neither distributions nor libvirt are there, yet. After all this text, I'm finally ready to curve towards -blockdev. Going from -drive if=T, T!=none to -blockdev involves two steps. The first step replaces if=T with if=none and -device. The second step replaces -drive if=none with -blockdev. That step is "obvious" (it took us a few years to get to obvious, but I digress). The difficulty is in the first step. Two issues: (1) cfi.pflash01 isn't available with -device. (2) "Magic board code picks up the backend [created for -drive if=pflash], creates a frontend (a cfi.pflash01 device), and maps it into the guest's address space." When we replace if=pflash by if=none, we get to replicate that magic on top of -device. Issue (1) isn't too hard: we add the device to the dynamic sysbus device white-list, move a sysbus_mmio_map() from pflash_cfi01_realize() into pflash_cfi01_realize(). The latter requires a new device property to configure the base address. I got a working prototype. Since this makes the device model's name and properties ABI, review would be advisable. To solve (2), we first have to understand the magic. Device cfi.pflash01 has the following properties: num-blocks Size of the device in blocks sector-length Size of a block (admire the choice of names) width Bank width big-endian Endianess (d'oh) id0, id1, id2, id3 Some kind of device ID, guest-visible, default to zero, few boards change it name Memory region name (why is this even configurable?) phys-addr Physical base address (this is the new device property mentioned above) secure For restricting access to firmware, default off device-width you don't want to know, there is a default, but it's documented as "bad, do not use", yet pretty much all boards use it max-device-width defaults to device-width not actually set anywhere old-multiple-chip-handling back-compat gunk for machine types 2.8 and older The magic board code in hw/i386/pc_sysfw.c configures as follows: num-blocks computed from backend size sector-length 4096 width 1 big-endian 0 id0, id1, id2, id3 all 0 name system.pflash<U>, where U is -drive's unit number phys-addr computed so unit 0 ends right below 0x100000000, unit n+1 ends at right below unit n "secure", "device-width", "max-device-width", "old-multiple-chip-handling" are left at the default. One additional bit of magic is actually in libvirt: it configures "secure" by flipping its default with -global driver=cfi.pflash01,property=secure,value=on. Now let's consider how to replicate this magic on top of device. Perhaps machine-type specific defaults could take care of sector-length, width, big-endian, id0, id1, id2, id3. Leaves num-blocks, name, and phys-addr. Perhaps the realize() method could default num-blocks to size of backend. But that doesn't really help the management application, because it needs to mess with the size anyway to compute phys-addr. So scratch that idea. Moving the magic code to compute num-blocks, phys-addr and name to the management application is certainly possible, but ugly. Note that the values computed are fixed when the firmware gets deployed. If we record them in the firmware descriptor, the management application doesn't need magic, it can simply pass on the values obtained from the descriptor. We'd want to include sector-length in the descriptor then, to ensure num-block has a defined meaning. Same technique could take care of width, big-endian, ... in case machine-type specific defaults turn out to be inadequate for them. Opinions? One more problem: the magic board code does a bit more than just configure the cfi.pflash01 device. That additional magic needs to be generalized to work regardless of whether the device gets configured with -drive if=pflash or with -device. I got a working prototype.

7 44

[libvirt] Plans for next release
by Daniel Veillard 22 Feb '19

22 Feb '19

So it's getting time to think about 5.1.0, I'm thinking about entering freeze on Monday next week, push rc2 Wed and if everything goes well we can have the release out on Friday 1st, I hope that works for everyone, Daniel P.S. I will be on west coast so freeze and pushes likely to be later in the day than usual. -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0