audio: new backend api (first part of the surround sound patch series).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJdibVzAAoJEEy22O7T6HE4FzIQAKhh+spepRDCWHr5Fp0Ur3pc
jo4ewzU7NJcth6lwWElpCt0P3rdscFBZefz0VeZ7alzYFD3lNryO9L6HBu5TvkgK
07KJfi6BJNo+rJfqF9+n+IP6eECKDeKgubZzcTQ8q4cu7BDSu8LiM1lds70HgcSN
1R/ddnwI0Xoo053M7CFVUEoux15wo5/SxP9atZz3ZkTBru2ZoHLHM9ZrQ2g0WOVs
ewBCOGANhEudbq3QgYHVhuYDXy5SY4Mew9E3hbXOv0WdOV+AJ96A94oAyPC5aGdZ
k/U8PhyNRnFzFsyyWHt/Cuxg1ArrYb0JEOJKTrcOsZVjX3QCTb8fyV9MVU80wym2
PU8if5UGxz1wS+JPLOaaoLXNo3Drjbmk4c1cZRUU2d/Exv9DTiV34DB1fqkq4WOQ
XEzVmnSYjjq4Rzfed9shPQpeKWW0CmNn6rKheIYjsqDJvF86VkCOVZ26G2GJf+KI
g15UhncidNtmFncP3LzE84+SElE89bSu0pvt0vkXv1SexVVopJI/LuT02uZL/Ok9
Y4+uZURUPhOm8XA93gczSPY3WJgQ6ljRGUZlWFQNMsurBfJQGlDSSVKCxCmD8Mve
RM+bljni+sVKY4V6HODFS5rkEcgb5eHoFZEH6UdIyecGBFlhfMsdE53Nt/+Pyupc
Zft180C00DMD2NxwNS1k
=w6YQ
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/kraxel/tags/audio-20190924-pull-request' into staging
audio: documentation fixes.
audio: new backend api (first part of the surround sound patch series).
# gpg: Signature made Tue 24 Sep 2019 07:19:31 BST
# gpg: using RSA key 4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full]
# gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full]
# gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full]
# Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138
* remotes/kraxel/tags/audio-20190924-pull-request:
audio: split ctl_* functions into enable_* and volume_*
audio: common rate control code for timer based outputs
audio: unify input and output mixeng buffer management
audio: remove remains of the old backend api
wavaudio: port to the new audio backend api
spiceaudio: port to the new audio backend api
sdlaudio: port to the new audio backend api
paaudio: port to the new audio backend api
ossaudio: port to the new audio backend api
noaudio: port to the new audio backend api
dsoundaudio: port to the new audio backend api
coreaudio: port to the new audio backend api
alsaaudio: port to the new audio backend api
audio: api for mixeng code free backends
audio: fix ALSA period-length typo in documentation
audio: fix buffer-length typo in documentation
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Some bug fixes for the watchdog and hopeful the BT tests.
Change the IPMI UUID handling to give the user the ability to set it or
not have it.
Add a PCI interface.
Add an SMBus interfaces.
-corey
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE/Q1c5nzg9ZpmiCaGYfOMkJGb/4EFAl2FJFkACgkQYfOMkJGb
/4ELTQ//csJVqXnjaeQUO6snd6X2QTBF62349RcVyontNNT5MSNTeyelvNYEZY3W
I8vSjvaYVwK2XkVMLAw0E1I9HlgLEVJt/Kas7r6Ka7IC7QhyCo6XioQAcWjtjnsK
LrpKjWfbswlkxeIP+dpzXT1zjiB46CjSApJmlelo3A35iSRLQGJMbohPs0edzeUr
GtzTkJrOpeSFRmWVKPqpVX5cJUqXrdKgXTnUciSN1uHQqjXDCYlQQqlYuYfAJxbY
zp9Zli/nJXuTHSGNg7OfTGPqePIUt+U/2bNVM9aT1TgMpedvy4KdUNqebiMhJlE/
rrylXId9kpGyTYxJLllTyFC03ay3MIn/HeQDFBjlwA1PGH7wrAST4jddiDTuVJEd
vSbo59Ek6v+1wuIgCZMsof9A/t3G/JmBClnsxS2FA6VNFO3+Y5J94o8Uqz5uZvwZ
yEMfgGODNqO33VMBlMchyW0flxsn5F3kAKzARZf1ifhJZta8mCnyf7jmJ2A0hROQ
5LnWn/FUZjQ5kaiNAotzHxF3tWleY0rnp7wgmeQrA+5fJHki0CyMNJ6MNbkDTeW9
rfI8iHQHp4dQk1ZSq5C6OsEeNfPERgyCRCJdGgh5BACeyZbgAqctxC2hH2iWe89n
Kc9SiZQrWHsCWWPZIXadTKkbcykLl8CaBVOX9hAz5VdV0qmmx6w=
=lCyp
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/cminyard/tags/ipmi-for-release-2019-09-20' into staging
ipmi: Some bug fixes and new interfaces
Some bug fixes for the watchdog and hopeful the BT tests.
Change the IPMI UUID handling to give the user the ability to set it or
not have it.
Add a PCI interface.
Add an SMBus interfaces.
-corey
# gpg: Signature made Fri 20 Sep 2019 20:11:21 BST
# gpg: using RSA key FD0D5CE67CE0F59A6688268661F38C90919BFF81
# gpg: Good signature from "Corey Minyard <cminyard@mvista.com>" [unknown]
# gpg: aka "Corey Minyard <minyard@acm.org>" [unknown]
# gpg: aka "Corey Minyard <corey@minyard.net>" [unknown]
# gpg: aka "Corey Minyard <minyard@mvista.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: FD0D 5CE6 7CE0 F59A 6688 2686 61F3 8C90 919B FF81
* remotes/cminyard/tags/ipmi-for-release-2019-09-20:
pc: Add an SMB0 ACPI device to q35
ipmi: Fix SSIF ACPI handling to use the right CRS
acpi: Add i2c serial bus CRS handling
ipmi: Add an SMBus IPMI interface
ipmi: Add PCI IPMI interfaces
smbios:ipmi: Ignore IPMI devices with no fwinfo function
ipmi: Allow a size value to be passed for I/O space
ipmi: Split out BT-specific code from ISA BT code
ipmi: Split out KCS-specific code from ISA KCS code
ipmi: Add a UUID device property
qdev: Add a no default uuid property
tests:ipmi: Fix IPMI BT tests
ipmi: Generate an interrupt on watchdog pretimeout expiry
ipmi: Fix the get watchdog command
ipmi: Fix watchdog NMI handling
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Using the UUID that qemu generates probably isn't the best thing
to do, allow it to be passed in via properties, and use QemuUUID
for the type.
If the UUID is not set, return an unsupported command error. This
way we are not providing an all-zero (or randomly generated) GUID
to the IPMI user. This lets the host fall back to the other
method of using the get device id command to determind the BMC
being accessed.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Cc: Cédric Le Goater <clg@kaod.org>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
We've got a separate option to configure the accelerator nowadays, which
is shorter to type and the preferred way of specifying an accelerator.
Use it in the source and examples to show that it is the favored option.
(However, do not touch the places yet which also specify other machine
options or multiple accelerators - these are currently still better
handled with one single "-machine" statement instead)
Signed-off-by: Thomas Huth <thuth@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20190904052739.22123-1-thuth@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
In our documentation, we use a mix of "$QEMU", "qemu-system-i386" and
"qemu-system-x86_64" when we give examples to the users how to run
QEMU. Some more consistency would be good here. Also some distributions
use different names for the QEMU binary (e.g. "qemu-kvm" in RHEL), so
providing more flexibility here would also be good. Thus let's define
some variables for the names of the QEMU command and use those in the
documentation instead: @value{qemu_system} for generic examples, and
@value{qemu_system_x86} for examples that only work with the x86
binaries.
Message-Id: <20190828093447.12441-1-thuth@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Reviewed-by: Miroslav Rezanina <mrezanin@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Add a new RNG backend using QEMU builtin getrandom function.
It can be created and used with something like:
... -object rng-builtin,id=rng0 -device virtio-rng,rng=rng0 ...
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Message-Id: <20190820160615.14616-2-lvivier@redhat.com>
The -usb section of the man page is not very clear on what exactly -usb
does and fails to mention xHCI as a modern alternative (-device
nec-usb-xhci).
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 20190815141428.29080-1-stefanha@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
For PC target, users could configure the number of dies per one package
via command line with this patch, such as "-smp dies=2,cores=4".
The parsing rules of new cpu-topology model obey the same restrictions/logic
as the legacy socket/core/thread model especially on missing values computing.
Signed-off-by: Like Xu <like.xu@linux.intel.com>
Message-Id: <20190620054525.37188-4-like.xu@linux.intel.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
When QEMU exposes a VirtIO-RNG device to the guest, that device needs a
source of entropy, and that source needs to be "non-blocking", like
`/dev/urandom`. However, currently QEMU defaults to the problematic
`/dev/random`, which on Linux is "blocking" (as in, it waits until
sufficient entropy is available).
Why prefer `/dev/urandom` over `/dev/random`?
---------------------------------------------
The man pages of urandom(4) and random(4) state:
"The /dev/random device is a legacy interface which dates back to a
time where the cryptographic primitives used in the implementation
of /dev/urandom were not widely trusted. It will return random
bytes only within the estimated number of bits of fresh noise in the
entropy pool, blocking if necessary. /dev/random is suitable for
applications that need high quality randomness, and can afford
indeterminate delays."
Further, the "Usage" section of the said man pages state:
"The /dev/random interface is considered a legacy interface, and
/dev/urandom is preferred and sufficient in all use cases, with the
exception of applications which require randomness during early boot
time; for these applications, getrandom(2) must be used instead,
because it will block until the entropy pool is initialized.
"If a seed file is saved across reboots as recommended below (all
major Linux distributions have done this since 2000 at least), the
output is cryptographically secure against attackers without local
root access as soon as it is reloaded in the boot sequence, and
perfectly adequate for network encryption session keys. Since reads
from /dev/random may block, users will usually want to open it in
nonblocking mode (or perform a read with timeout), and provide some
sort of user notification if the desired entropy is not immediately
available."
And refer to random(7) for a comparison of `/dev/random` and
`/dev/urandom`.
What about other OSes?
----------------------
`/dev/urandom` exists and works on OS-X, FreeBSD, DragonFlyBSD, NetBSD
and OpenBSD, which cover all the non-Linux platforms we explicitly
support, aside from Windows.
On Windows `/dev/random` doesn't work either so we don't regress.
This is actually another argument in favour of using the newly
proposed 'rng-builtin' backend by default, as that will work on
Windows.
- - -
Given the above, change the entropy source for VirtIO-RNG device to
`/dev/urandom`.
Related discussion in these[1][2] past threads.
[1] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg08335.html
-- "RNG: Any reason QEMU doesn't default to `/dev/urandom`?"
[2] https://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg02724.html
-- "[RFC] Virtio RNG: Consider changing the default entropy source to
/dev/urandom"
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Message-Id: <20190529143106.11789-2-lvivier@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
We add the "notify_dev=chardevID" parameter. After that colo-compare can connect with
remote(currently just for Xen, KVM-COLO didn't need it.) colo-frame through chardev socket,
it can notify remote(Xen) colo-frame to handle checkpoint event.
Signed-off-by: Zhang Chen <chen.zhang@intel.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
'family' option is not part of type 2 table and if user tries to use it
as such QEMU will error out with an unknow option error.
Drop it from docs lest it confuse users.
Fixes: b155eb1d04 ("smbios: document cmdline options for smbios type 2-4, 17 structures")
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1558448611-315074-1-git-send-email-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
It will be useful for a number of use-cases to be able to re-direct
output to a file like we do with serial output. This does the wiring
to allow us to treat then semihosting console like just another
character output device.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
When the -seed option is given, call qemu_guest_random_seed_main,
putting the subsystem into deterministic mode. Pass derived seeds
to each cpu created; which is a no-op unless the subsystem is in
deterministic mode.
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This fixes several things:
- add "id" description to -virtfs documentation
- split the description into several lines in both usage and documentation
for accurateness and clarity
- add documentation and usage of the synth fsdriver
- add "throttling.*" description to -fsdev local
- add some missing periods
- add proper reference to the virtfs-proxy-helper(1) manual page
- document that the virtio device may be either virtio-9p-pci, virtio-9p-ccw
or virtio-9p-device, depending on the machine type
Buglink: https://bugs.launchpad.net/qemu/+bug/1581976
Signed-off-by: Greg Kurz <groug@kaod.org>
Acked-by: Thomas Huth <thuth@redhat.com>
The synth fsdriver never got used for anything else but the QTest
testcase for VirtIO 9P. And even there, QTest uses -fsdev synth and
-device virtio-9p-... directly.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
We missed the iothread related args in this file.
This patch is used to fix this issue.
Signed-off-by: Zhang Chen <chen.zhang@intel.com>
Message-Id: <20190426090730.2691-4-chen.zhang@intel.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
This patch adds support for libgloss semihosting to Nios II bare-metal
emulation. The specification for the protocol can be found in the
libgloss sources.
Signed-off-by: Sandra Loosemore <sandra@codesourcery.com>
Signed-off-by: Julian Brown <julian@codesourcery.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1554321185-2825-3-git-send-email-sandra@codesourcery.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When a file supporting DAX is used as vNVDIMM backend, mmap it with
MAP_SYNC flag in addition which can ensure file system metadata
synced in each guest writes to the backend file, without other QEMU
actions (e.g., periodic fsync() by QEMU).
Current, We have below different possible use cases:
1. pmem=on is set, shared=on is set, MAP_SYNC supported:
a: backend is a dax supporting file.
- MAP_SYNC will active.
b: backend is not a dax supporting file.
- mmap will trigger a warning. then MAP_SYNC flag will be ignored
2. The rest of cases:
- we will never pass the MAP_SYNC to mmap2
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Signed-off-by: Zhang Yi <yi.z.zhang@linux.intel.com>
[ehabkost: Rebased patch to latest code on master]
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Tested-by: Wei Yang <richardw.yang@linux.intel.com>
Message-Id: <20190422004849.26463-2-richardw.yang@linux.intel.com>
[ehabkost: squashed documentation patch]
Message-Id: <20190422004849.26463-3-richardw.yang@linux.intel.com>
[ehabkost: documentation fixup]
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Pankaj Gupta <pagupta@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
This uses iconv to convert glyphs from the specified VGA font encoding to
unicode, and makes use of cchar_t instead of chtype when using ncursesw,
which allows to store all wide char as well as the WACS values. The default
charset is made CP437 since that is the charset of the hardware default VGA
font. This also makes the curses backend set the LC_CTYPE locale to "" to
allow curses to emit wide characters.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Eddie Kohler <ekohler@gmail.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190311135127.2229-3-samuel.thibault@ens-lyon.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently any client which can complete the TLS handshake is able to use
a chardev server. The server admin can turn on the 'verify-peer' option
for the x509 creds to require the client to provide a x509
certificate. This means the client will have to acquire a certificate
from the CA before they are permitted to use the chardev server. This is
still a fairly low bar.
This adds a 'tls-authz=OBJECT-ID' option to the socket chardev backend
which takes the ID of a previously added 'QAuthZ' object instance. This
will be used to validate the client's x509 distinguished name. Clients
failing the check will not be permitted to use the chardev server.
For example to setup authorization that only allows connection from a
client whose x509 certificate distinguished name contains 'CN=fred', you
would use:
$QEMU -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
-object authz-simple,id=authz0,identity=CN=laptop.example.com,,\
O=Example Org,,L=London,,ST=London,,C=GB \
-chardev socket,host=127.0.0.1,port=9000,server,\
tls-creds=tls0,tls-authz=authz0 \
...other qemu args...
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
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@gmail.com>
Message-id: ca5e761e58dcfaf591cf46080af3548551b42bb2.1552083282.git.DirtY.iCE.hu@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The VNC server has historically had support for ACLs to check both the
SASL username and the TLS x509 distinguished name. The VNC server was
responsible for creating the initial ACL, and the client app was then
responsible for populating it with rules using the HMP 'acl_add' command.
This is not satisfactory for a variety of reasons. There is no way to
populate the ACLs from the command line, users are forced to use the
HMP. With multiple network services all supporting TLS and ACLs now, it
is desirable to be able to define a single ACL that is referenced by all
services.
To address these limitations, two new options are added to the VNC
server CLI. The 'tls-authz' option takes the ID of a QAuthZ object to
use for checking TLS x509 distinguished names, and the 'sasl-authz'
option takes the ID of another object to use for checking SASL usernames.
In this example, we setup two authorization rules. The first allows any
client with a certificate issued by the 'RedHat' organization in the
'London' locality. The second ACL allows clients with either the
'joe@REDHAT.COM' or 'fred@REDHAT.COM' kerberos usernames. Both checks
must pass for the user to be allowed.
$QEMU -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
-object authz-simple,id=authz0,policy=deny,\
rules.0.match=O=RedHat,,L=London,rules.0.policy=allow \
-object authz-simple,id=authz1,policy=deny,\
rules.0.match=fred@REDHAT.COM,rules.0.policy=allow \
rules.0.match=joe@REDHAT.COM,rules.0.policy=allow \
-vnc 0.0.0.0:1,tls-creds=tls0,tls-authz=authz0,
sasl,sasl-authz=authz1 \
...other QEMU args...
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20190227145755.26556-2-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add an authorization backend that talks to PAM to check whether the user
identity is allowed. This only uses the PAM account validation facility,
which is essentially just a check to see if the provided username is permitted
access. It doesn't use the authentication or session parts of PAM, since
that's dealt with by the relevant part of QEMU (eg VNC server).
Consider starting QEMU with a VNC server and telling it to use TLS with
x509 client certificates and configuring it to use an PAM to validate
the x509 distinguished name. In this example we're telling it to use PAM
for the QAuthZ impl with a service name of "qemu-vnc"
$ qemu-system-x86_64 \
-object tls-creds-x509,id=tls0,dir=/home/berrange/security/qemutls,\
endpoint=server,verify-peer=yes \
-object authz-pam,id=authz0,service=qemu-vnc \
-vnc :1,tls-creds=tls0,tls-authz=authz0
This requires an /etc/pam/qemu-vnc file to be created with the auth
rules. A very simple file based whitelist can be setup using
$ cat > /etc/pam/qemu-vnc <<EOF
account requisite pam_listfile.so item=user sense=allow file=/etc/qemu/vnc.allow
EOF
The /etc/qemu/vnc.allow file simply contains one username per line. Any
username not in the file is denied. The usernames in this example are
the x509 distinguished name from the client's x509 cert.
$ cat > /etc/qemu/vnc.allow <<EOF
CN=laptop.berrange.com,O=Berrange Home,L=London,ST=London,C=GB
EOF
More interesting would be to configure PAM to use an LDAP backend, so
that the QEMU authorization check data can be centralized instead of
requiring each compute host to have file maintained.
The main limitation with this PAM module is that the rules apply to all
QEMU instances on the host. Setting up different rules per VM, would
require creating a separate PAM service name & config file for every
guest. An alternative approach for the future might be to not pass in
the plain username to PAM, but instead combine the VM name or UUID with
the username. This requires further consideration though.
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Add a QAuthZListFile object type that implements the QAuthZ interface. This
built-in implementation is a proxy around the QAuthZList object type,
initializing it from an external file, and optionally, automatically
reloading it whenever it changes.
To create an instance of this object via the QMP monitor, the syntax
used would be:
{
"execute": "object-add",
"arguments": {
"qom-type": "authz-list-file",
"id": "authz0",
"props": {
"filename": "/etc/qemu/vnc.acl",
"refresh": true
}
}
}
If "refresh" is "yes", inotify is used to monitor the file,
automatically reloading changes. If an error occurs during reloading,
all authorizations will fail until the file is next successfully
loaded.
The /etc/qemu/vnc.acl file would contain a JSON representation of a
QAuthZList object
{
"rules": [
{ "match": "fred", "policy": "allow", "format": "exact" },
{ "match": "bob", "policy": "allow", "format": "exact" },
{ "match": "danb", "policy": "deny", "format": "glob" },
{ "match": "dan*", "policy": "allow", "format": "exact" },
],
"policy": "deny"
}
This sets up an authorization rule that allows 'fred', 'bob' and anyone
whose name starts with 'dan', except for 'danb'. Everyone unmatched is
denied.
The object can be loaded on the comand line using
-object authz-list-file,id=authz0,filename=/etc/qemu/vnc.acl,refresh=yes
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In many cases a single VM will just need to whitelist a single identity
as the allowed user of network services. This is especially the case for
TLS live migration (optionally with NBD storage) where we just need to
whitelist the x509 certificate distinguished name of the source QEMU
host.
Via QMP this can be configured with:
{
"execute": "object-add",
"arguments": {
"qom-type": "authz-simple",
"id": "authz0",
"props": {
"identity": "fred"
}
}
}
Or via the command line
-object authz-simple,id=authz0,identity=fred
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Add a new display backend that will configure Spice to allow a remote
client to control QEMU in a similar fashion as other QEMU display
backend/UI like GTK.
For this to work, it will set up Spice server with a unix socket, and
register a VC chardev that will be exposed as Spice ports. A QMP
monitor is also exposed as a Spice port, this allows the remote client
fuller qemu control and state handling.
- doesn't handle VC set_echo() - this doesn't seem a strong
requirement, very few front-end use it
- spice options can be tweaked with other -spice arguments
- Windows support shouldn't be hard to do, but will probably use a TCP
port instead
- we may want to watch the child process to quit automatically if it
crashed
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Tested-by: Victor Toso <victortoso@redhat.com>
Message-id: 20190221110703.5775-12-marcandre.lureau@redhat.com
[ kraxel: squash incremental fix ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The option is only a dummy since a long time. We've finally deprecated
it in QEMU v3.0, so it's time to remove it now.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <1549545296-18903-3-git-send-email-thuth@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
It's been deprecated since QEMU 3.0, and nobody complained so far, so
it is time to remove this option now.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1544684731-18828-1-git-send-email-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Our command line interface is really quite overcrowded, we should avoid
duplicated options that do the same thing in just a slightly different
way. "-accel hax" is shorter and more generic that "-enable-hax", so
there is really no real usage for the latter option. "-enable-hax" has
been deprecated since two releases, and nobody complained so far, so
it's time to remove this now.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1544790073-23049-1-git-send-email-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The -no-frame option has been deprecated with QEMU v2.12. It was only
useful with SDL1.2 - now that we've removed support for SDL1.2, we
can certainly remove the -no-frame option, too.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1549351769-19620-1-git-send-email-thuth@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
xend have been replaced by libxenlight (libxl) for many Xen releases
now.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
It is broken since Xen 4.9 [1] and it will not build in Xen 4.12. Also,
it is not built by default since QEMU 2.6.
[1] https://lists.xenproject.org/archives/html/xen-devel/2018-09/msg00313.html
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
macOS provides pthread_setname_np that doesn't have thread id argument.
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The "handle" fsdev backend was deprecated in QEMU 2.12.0 with:
commit db3b3c7281
Author: Greg Kurz <groug@kaod.org>
Date: Mon Jan 8 11:18:23 2018 +0100
9pfs: deprecate handle backend
This backend raise some concerns:
- doesn't support symlinks
- fails +100 tests in the PJD POSIX file system test suite [1]
- requires the QEMU process to run with the CAP_DAC_READ_SEARCH
capability, which isn't recommended for security reasons
This backend should not be used and wil be removed. The 'local'
backend is the recommended alternative.
[1] https://www.tuxera.com/community/posix-test-suite/
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
It has passed the two release cooling period without any complaint.
Remove it now.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
The share=on/off property is used to modified mmap() MAP_SHARED
setting. Make it on by default for convenience and compatibility
reasons.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
EGL headless has been missing from QEMU's help or man page, we should
mention that such a thing exists, especially since projects like libvirt
might rely on that. This patch also adds the newly introduced option for
egl-headless 'rendernode'.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Message-id: 87ef678b0934d3abba66c46c9e65b57119d29295.1542362949.git.eskultet@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
It has been unmaintained since years, and there were only trivial or
tree-wide changes to the related files since many years, so the
code is likely very bitrotten and broken. For example the following
segfaults as soon as as you press a key:
qemu-system-x86_64 -usb -device usb-bt-dongle -bt hci -bt device:keyboard
Since we are not aware of anybody using bluetooth with the current
version of QEMU, let's mark the subsystem as deprecated, with a special
request for the users to write to the qemu-devel mailing list in case
they still use it (so we could revert the deprecation status in that
case).
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1542016830-19189-1-git-send-email-thuth@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
New option "websocket" added to allow using WebSocket protocol for
chardev socket backend.
Example:
-chardev socket,websocket,server,id=...
Signed-off-by: Julia Suvorova <jusual@mail.ru>
Message-Id: <20181018223501.21683-3-jusual@mail.ru>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This new usernet option can be used to add data for option 66 (tftp
server name) in the BOOTP reply, which is useful in PXE based automatic
OS install such as OpenBSD.
Signed-off-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Documentation describing -rtc option updated to better match current
implementation and highlight some important specifics.
Signed-off-by: Artem Pisarenko <artem.k.pisarenko@gmail.com>
Message-Id: <1b245c6c0803d4bf11dcbf9eb32f34af8c2bd0b4.1539846575.git.artem.k.pisarenko@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
