neulab/tldr huggingface dataset:
The share boolean option determines whether the memory region is marked as private to QEMU, or shared. The latter allows a co-operating external process to access the QEMU memory region.
The share is also required for pvrdma devices due to limitations in the RDMA API provided by Linux.
Setting share=on might affect the ability to configure NUMA bindings for the memory backend under some circumstances, see Documentation/vm/numa_memory_policy.txt on the Linux kernel source tree for additional details.
Setting the discard-data boolean option to on indicates that file contents can be destroyed when QEMU exits, to avoid unnecessarily flushing data to the backing file. Note that discard-data is only an optimization, and QEMU might not discard file contents if it aborts unexpectedly or is terminated using SIGKILL.
The merge boolean option enables memory merge, also known as MADV_MERGEABLE, so that Kernel Samepage Merging will consider the pages for memory deduplication.
Setting the dump boolean option to off excludes the memory from core dumps. This feature is also known as MADV_DONTDUMP.
The prealloc boolean option enables memory preallocation.
The host-nodes option binds the memory range to a list of NUMA host nodes.
The policy option sets the NUMA policy to one of the following values:
default default host policy
preferred prefer the given host node list for allocation
bind   restrict memory allocation to the given host node list
interleave interleave memory allocations across the given host node list
The align option specifies the base address alignment when QEMU mmap(2) mem-path, and accepts common suffixes, eg 2M. Some backend store specified by mem-path requires an alignment different than the default one used by QEMU, eg the device DAX /dev/dax0.0 requires 2M alignment rather than 4K. In such cases, users can specify the required alignment via this option.
The pmem option specifies whether the backing file specified by mem-path is in host persistent memory that can be accessed using the SNIA NVM programming model (e.g. Intel NVDIMM). If pmem is set to 'on', QEMU will take necessary operations to guarantee the persistence of its own writes to mem-path (e.g. in vNVDIMM label emulation and live migration). Also, we will map the backend-file with MAP_SYNC flag, which ensures the file metadata is in sync for mem-path in case of host crash or a power failure. MAP_SYNC requires support from both the host kernel (since Linux kernel 4.15) and the filesystem of mem-path mounted with DAX option.
The readonly option specifies whether the backing file is opened read-only or read-write (default).
-object memory-backend-ram,id=id,merge=on|off,dump=on|off,share=on|off,prealloc=on|off,size=size,host-nodes=host-nodes,policy=default|preferred|bind|interleave Creates a memory backend object, which can be used to back the guest RAM. Memory backend objects offer more control than the -m option that is traditionally used to define guest RAM.  Please refer to memory-backend-file for a description of the options.
-object memory-backend-memfd,id=id,merge=on|off,dump=on|off,share=on|off,prealloc=on|off,size=size,host-nodes=host-nodes,policy=default|preferred|bind|interleave,seal=on|off,hugetlb=on|off,hugetlbsize=size Creates an anonymous memory file backend object, which allows QEMU to share the memory with an external process (e.g. when using vhost-user). The memory is allocated with memfd and optional sealing. (Linux only)
The seal option creates a sealed-file, that will block further resizing the memory ('on' by default).
The hugetlb option specify the file to be created resides in the hugetlbfs filesystem (since Linux 4.14). Used in conjunction with the hugetlb option, the hugetlbsize option specify the hugetlb page size on systems that support multiple hugetlb page sizes (it must be a power of 2 value supported by the system).
In some versions of Linux, the hugetlb option is incompatible with the seal option (requires at least Linux 4.16).
Please refer to memory-backend-file for a description of the other options.
The share boolean option is on by default with memfd.
-object rng-builtin,id=id Creates a random number generator backend which obtains entropy from QEMU builtin functions. The id parameter is a unique ID that will be used to reference this entropy backend from the virtio-rng device. By default, the virtio-rng device uses this RNG backend.
-object rng-random,id=id,filename=/dev/random Creates a random number generator backend which obtains entropy from a device on the host. The id parameter is a unique ID that will be used to reference this entropy backend from the virtio-rng device. The filename parameter specifies which file to obtain entropy from and if omitted defaults to /dev/urandom.
-object rng-egd,id=id,chardev=chardevid Creates a random number generator backend which obtains entropy from an external daemon running on the host. The id parameter is a unique ID that will be used to reference this entropy backend from the virtio-rng device. The chardev parameter is the unique ID of a character device backend that provides the connection to the RNG daemon.
-object tls-creds-anon,id=id,endpoint=endpoint,dir=/path/to/cred/dir,verify-peer=on|off Creates a TLS anonymous credentials object, which can be used to provide TLS support on network backends. The id parameter is a unique ID which network backends will use to access the credentials. The endpoint is either server or client depending on whether the QEMU network backend that uses the credentials will be acting as a client or as a server. If verify-peer is enabled (the default) then once the handshake is completed, the peer credentials will be verified, though this is a no-op for anonymous credentials.
The dir parameter tells QEMU where to find the credential files.  For server endpoints, this directory may contain a file dh-params.pem providing diffie-hellman parameters to use for the TLS server. If the file is missing, QEMU will generate a set of DH parameters at startup. This is a computationally expensive operation that consumes random pool entropy, so it is recommended that a persistent set of parameters be generated upfront and saved.
-object tls-creds-psk,id=id,endpoint=endpoint,dir=/path/to/keys/dir[,username=username] Creates a TLS Pre-Shared Keys (PSK) credentials object, which can be used to provide TLS support on network backends. The id parameter is a unique ID which network backends will use to access the credentials. The endpoint is either server or client depending on whether the QEMU network backend that uses the credentials will be acting as a client or as a server.  For clients only, username is the username which will be sent to the server. If omitted it defaults to "qemu".
The dir parameter tells QEMU where to find the keys file. It is called "dir/keys.psk" and contains "username:key" pairs. This file can most easily be created using the GnuTLS psktool program.
For server endpoints, dir may also contain a file dh-params.pem providing diffie-hellman parameters to use for the TLS server.  If the file is missing, QEMU will generate a set of DH parameters at startup. This is a computationally expensive operation that consumes random pool entropy, so it is recommended that a persistent set of parameters be generated up front and saved.
-object tls-creds-x509,id=id,endpoint=endpoint,dir=/path/to/cred/dir,priority=priority,verify-peer=on|off,passwordid=id Creates a TLS anonymous credentials object, which can be used to provide TLS support on network backends. The id parameter is a unique ID which network backends will use to access the credentials. The endpoint is either server or client depending on whether the QEMU network backend that uses the credentials will be acting as a client or as a server. If verify-peer is enabled (the default) then once the handshake is completed, the peer credentials will be verified. With x509 certificates, this implies that the clients must be provided with valid client certificates too.
For x509 certificate credentials the directory will contain further files providing the x509 certificates. The certificates must be stored in PEM format, in filenames ca-cert.pem, ca-crl.pem (optional), server-cert.pem (only servers), server-key.pem (only servers), client-cert.pem (only clients), and client-key.pem (only clients).
For the server-key.pem and client-key.pem files which contain sensitive private keys, it is possible to use an encrypted version by providing the passwordid parameter. This provides the ID of a previously created secret object containing the password for decryption.
The priority parameter allows to override the global default priority used by gnutls. This can be useful if the system administrator needs to use a weaker set of crypto priorities for QEMU without potentially forcing the weakness onto all applications. Or conversely if one wants wants a stronger default for QEMU than for all other applications, they can do this through this parameter. Its format is a gnutls priority string as described at https://gnutls.org/manual/html_node/Priority-Strings.html.
-object tls-cipher-suites,id=id,priority=priority Creates a TLS cipher suites object, which can be used to control the TLS cipher/protocol algorithms that applications are permitted to use.
The id parameter is a unique ID which frontends will use to access the ordered list of permitted TLS cipher suites from the host.
An example of use of this object is to control UEFI HTTPS Boot.  The tls-cipher-suites object exposes the ordered list of permitted TLS cipher suites from the host side to the guest firmware, via fw_cfg. The list is represented as an array of IANA_TLS_CIPHER objects. The firmware uses the IANA_TLS_CIPHER array for configuring guest-side TLS.
In the following example, the priority at which the host-side policy is retrieved is given by the priority property.  Given that QEMU uses GNUTLS, priority=@SYSTEM may be used to refer to /etc/crypto-policies/back-ends/gnutls.config.
# qemu-system-x86_64 \ -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \ -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
-object filter-buffer,id=id,netdev=netdevid,interval=t[,queue=all|rx|tx][,status=on|off][,position=head|tail|id=<id>][,insert=behind|before] Interval t can't be 0, this filter batches the packet delivery: all packets arriving in a given interval on netdev netdevid are delayed until the end of the interval. Interval is in microseconds. status is optional that indicate whether the netfilter is on (enabled) or off (disabled), the default status for netfilter will be 'on'.
queue all|rx|tx is an option that can be applied to any netfilter.
all: the filter is attached both to the receive and the transmit queue of the netdev (default).
rx: the filter is attached to the receive queue of the netdev, where it will receive packets sent to the netdev.
tx: the filter is attached to the transmit queue of the netdev, where it will receive packets sent by the netdev.
position head|tail|id=<id> is an option to specify where the filter should be inserted in the filter list. It can be applied to any netfilter.
head: the filter is inserted at the head of the filter list, before any existing filters.
tail: the filter is inserted at the tail of the filter list, behind any existing filters (default).
id=<id>: the filter is inserted before or behind the filter specified by <id>, see the insert option below.
insert behind|before is an option to specify where to insert the new filter relative to the one specified with position=id=<id>. It can be applied to any netfilter.
before: insert before the specified filter.
behind: insert behind the specified filter (default).
-object filter-mirror,id=id,netdev=netdevid,outdev=chardevid,queue=all|rx|tx[,vnet_hdr_support][,position=head|tail|id=<id>][,insert=behind|before] filter-mirror on netdev netdevid,mirror net packet to chardevchardevid, if it has the vnet_hdr_support flag, filter-mirror will mirror packet with vnet_hdr_len.
-object filter-redirector,id=id,netdev=netdevid,indev=chardevid,outdev=chardevid,queue=all|rx|tx[,vnet_hdr_support][,position=head|tail|id=<id>][,insert=behind|before] filter-redirector on netdev netdevid,redirect filter's net packet to chardev chardevid,and redirect indev's packet to filter.if it has the vnet_hdr_support flag, filter-redirector will redirect packet with vnet_hdr_len. Create a filter-redirector we need to differ outdev id from indev id, id can not be the same. we can just use indev or outdev, but at least one of indev or outdev need to be specified.
-object filter-rewriter,id=id,netdev=netdevid,queue=all|rx|tx,[vnet_hdr_support][,position=head|tail|id=<id>][,insert=behind|before] Filter-rewriter is a part of COLO project.It will rewrite tcp packet to secondary from primary to keep secondary tcp connection,and rewrite tcp packet to primary from secondary make tcp packet can be handled by client.if it has the vnet_hdr_support flag, we can parse packet with vnet header.
usage: colo secondary: -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 -object filter-rewriter,id=rew0,netdev=hn0,queue=all
-object filter-dump,id=id,netdev=dev[,file=filename][,maxlen=len][,position=head|tail|id=<id>][,insert=behind|before] Dump the network traffic on netdev dev to the file specified by filename. At most len bytes (64k by default) per packet are stored. The file format is libpcap, so it can be analyzed with tools such as tcpdump or Wireshark.
-object colo-compare,id=id,primary_in=chardevid,secondary_in=chardevid,outdev=chardevid,iothread=id[,vnet_hdr_support][,notify_dev=id][,compare_timeout=@var{ms}][,expired_scan_cycle=@var{ms}][,max_queue_size=@var{size}] Colo-compare gets packet from primary_in chardevid and secondary_in, then compare whether the payload of primary packet and secondary packet are the same. If same, it will output primary packet to out_dev, else it will notify COLO-framework to do checkpoint and send primary packet to out_dev. In order to improve efficiency, we need to put the task of comparison in another iothread. If it has the vnet_hdr_support flag, colo compare will send/recv packet with vnet_hdr_len.  The compare_timeout=@var{ms} determines the maximum time of the colo-compare hold the packet. The expired_scan_cycle=@var{ms} is to set the period of scanning expired primary node network packets.  The max_queue_size=@var{size} is to set the max compare queue size depend on user environment.  If user want to use Xen COLO, need to add the notify_dev to notify Xen colo-frame to do checkpoint.
COLO-compare must be used with the help of filter-mirror, filter-redirector and filter-rewriter.
KVM COLO
primary: -netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -device e1000,id=e0,netdev=hn0,mac=52:a4:00:12:78:66 -chardev socket,id=mirror0,host=3.3.3.3,port=9003,server=on,wait=off -chardev socket,id=compare1,host=3.3.3.3,port=9004,server=on,wait=off -chardev socket,id=compare0,host=3.3.3.3,port=9001,server=on,wait=off -chardev socket,id=compare0-0,host=3.3.3.3,port=9001 -chardev socket,id=compare_out,host=3.3.3.3,port=9005,server=on,wait=off -chardev socket,id=compare_out0,host=3.3.3.3,port=9005 -object iothread,id=iothread1 -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,outdev=compare_out0,iothread=iothread1
secondary: -netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,down script=/etc/qemu-ifdown -device e1000,netdev=hn0,mac=52:a4:00:12:78:66 -chardev socket,id=red0,host=3.3.3.3,port=9003 -chardev socket,id=red1,host=3.3.3.3,port=9004 -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1
Xen COLO
primary: -netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -device e1000,id=e0,netdev=hn0,mac=52:a4:00:12:78:66 -chardev socket,id=mirror0,host=3.3.3.3,port=9003,server=on,wait=off -chardev socket,id=compare1,host=3.3.3.3,port=9004,server=on,wait=off -chardev socket,id=compare0,host=3.3.3.3,port=9001,server=on,wait=off -chardev socket,id=compare0-0,host=3.3.3.3,port=9001 -chardev socket,id=compare_out,host=3.3.3.3,port=9005,server=on,wait=off -chardev socket,id=compare_out0,host=3.3.3.3,port=9005 -chardev socket,id=notify_way,host=3.3.3.3,port=9009,server=on,wait=off -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 -object iothread,id=iothread1 -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,outdev=compare_out0,notify_dev=nofity_way,iothread=iothread1
If you want to know the detail of above command line, you can read the colo-compare git log.
-object cryptodev-backend-builtin,id=id[,queues=queues] Creates a cryptodev backend which executes crypto opreation from the QEMU cipher APIS. The id parameter is a unique ID that will be used to reference this cryptodev backend from the virtio-crypto device. The queues parameter is optional, which specify the queue number of cryptodev backend, the default of queues is 1.
# qemu-system-x86_64 \ [...] \ -object cryptodev-backend-builtin,id=cryptodev0 \ -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \ [...]
-object cryptodev-vhost-user,id=id,chardev=chardevid[,queues=queues] Creates a vhost-user cryptodev backend, backed by a chardev chardevid. The id parameter is a unique ID that will be used to reference this cryptodev backend from the virtio-crypto device. The chardev should be a unix domain socket backed one.  The vhost-user uses a specifically defined protocol to pass vhost ioctl replacement messages to an application on the other end of the socket. The queues parameter is optional, which specify the queue number of cryptodev backend for multiqueue vhost-user, the default of queues is 1.
# qemu-system-x86_64 \ [...] \ -chardev socket,id=chardev0,path=/path/to/socket \ -object cryptodev-vhost-user,id=cryptodev0,chardev=chardev0 \ -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \ [...]
-object secret,id=id,data=string,format=raw|base64[,keyid=secretid,iv=string]
-object secret,id=id,file=filename,format=raw|base64[,keyid=secretid,iv=string] Defines a secret to store a password, encryption key, or some other sensitive data. The sensitive data can either be passed directly via the data parameter, or indirectly via the file parameter. Using the data parameter is insecure unless the sensitive data is encrypted.
The sensitive data can be provided in raw format (the default), or base64. When encoded as JSON, the raw format only supports valid UTF-8 characters, so base64 is recommended for sending binary data. QEMU will convert from which ever format is provided to the format it needs internally. eg, an RBD password can be provided in raw format, even though it will be base64 encoded when passed onto the RBD sever.
For added protection, it is possible to encrypt the data associated with a secret using the AES-256-CBC cipher. Use of encryption is indicated by providing the keyid and iv parameters. The keyid parameter provides the ID of a previously defined secret that contains the AES-256 decryption key. This key should be 32-bytes long and be base64 encoded. The iv parameter provides the random initialization vector used for encryption of this particular secret and should be a base64 encrypted string of the 16-byte IV.
The simplest (insecure) usage is to provide the secret inline
# qemu-system-x86_64 -object secret,id=sec0,data=letmein,format=raw
The simplest secure usage is to provide the secret via a file
# printf "letmein" > mypasswd.txt # QEMU_SYSTEM_MACRO -object secret,id=sec0,file=mypasswd.txt,format=raw
For greater security, AES-256-CBC should be used. To illustrate usage, consider the openssl command line tool which can encrypt the data. Note that when encrypting, the plaintext must be padded to the cipher block size (32 bytes) using the standard PKCS#5/6 compatible padding algorithm.
First a master key needs to be created in base64 encoding:
# openssl rand -base64 32 > key.b64 # KEY=$(base64 -d key.b64 | hexdump  -v -e '/1 "%02X"')
Each secret to be encrypted needs to have a random initialization vector generated. These do not need to be kept secret
# openssl rand -base64 16 > iv.b64 # IV=$(base64 -d iv.b64 | hexdump  -v -e '/1 "%02X"')
The secret to be defined can now be encrypted, in this case we're telling openssl to base64 encode the result, but it could be left as raw bytes if desired.
# SECRET=$(printf "letmein" | openssl enc -aes-256-cbc -a -K $KEY -iv $IV)
When launching QEMU, create a master secret pointing to key.b64 and specify that to be used to decrypt the user password. Pass the contents of iv.b64 to the second secret
# qemu-system-x86_64 \ -object secret,id=secmaster0,format=base64,file=key.b64 \ -object secret,id=sec0,keyid=secmaster0,format=base64,\ data=$SECRET,iv=$(<iv.b64)
-object sev-guest,id=id,cbitpos=cbitpos,reduced-phys-bits=val,[sev-device=string,policy=policy,handle=handle,dh-cert-file=file,session-file=file] Create a Secure Encrypted Virtualization (SEV) guest object, which can be used to provide the guest memory encryption support on AMD processors.
When memory encryption is enabled, one of the physical address bit (aka the C-bit) is utilized to mark if a memory page is protected. The cbitpos is used to provide the C-bit position. The C-bit position is Host family dependent hence user must provide this value. On EPYC, the value should be 47.
When memory encryption is enabled, we loose certain bits in physical address space. The reduced-phys-bits is used to provide the number of bits we loose in physical address space.  Similar to C-bit, the value is Host family dependent. On EPYC, the value should be 5.
The sev-device provides the device file to use for communicating with the SEV firmware running inside AMD Secure Processor. The default device is '/dev/sev'. If hardware supports memory encryption then /dev/sev devices are created by CCP driver.
The policy provides the guest policy to be enforced by the SEV firmware and restrict what configuration and operational commands can be performed on this guest by the hypervisor. The policy should be provided by the guest owner and is bound to the guest and cannot be changed throughout the lifetime of the guest. The default is 0.
If guest policy allows sharing the key with another SEV guest then handle can be use to provide handle of the guest from which to share the key.
The dh-cert-file and session-file provides the guest owner's Public Diffie-Hillman key defined in SEV spec. The PDH and session parameters are used for establishing a cryptographic session with the guest owner to negotiate keys used for attestation. The file must be encoded in base64.
e.g to launch a SEV guest
# qemu-system-x86_64 \ ...... \ -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=5 \ -machine ...,memory-encryption=sev0 \ .....
-object authz-simple,id=id,identity=string Create an authorization object that will control access to network services.
The identity parameter is identifies the user and its format depends on the network service that authorization object is associated with. For authorizing based on TLS x509 certificates, the identity must be the x509 distinguished name. Note that care must be taken to escape any commas in the distinguished name.
An example authorization object to validate a x509 distinguished name would look like:
# qemu-system-x86_64 \ ... \ -object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,O=Example Org,,L=London,,ST=London,,C=GB' \ ...
Note the use of quotes due to the x509 distinguished name containing whitespace, and escaping of ','.
-object authz-listfile,id=id,filename=path,refresh=on|off Create an authorization object that will control access to network services.
The filename parameter is the fully qualified path to a file containing the access control list rules in JSON format.
An example set of rules that match against SASL usernames might look like:
{ "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" }
When checking access the object will iterate over all the rules and the first rule to match will have its policy value returned as the result. If no rules match, then the default policy value is returned.
The rules can either be an exact string match, or they can use the simple UNIX glob pattern matching to allow wildcards to be used.
If refresh is set to true the file will be monitored and automatically reloaded whenever its content changes.
As with the authz-simple object, the format of the identity strings being matched depends on the network service, but is usually a TLS x509 distinguished name, or a SASL username.
An example authorization object to validate a SASL username would look like:
# qemu-system-x86_64 \ ... \ -object authz-simple,id=auth0,filename=/etc/qemu/vnc-sasl.acl,refresh=on \ ...
-object authz-pam,id=id,service=string Create an authorization object that will control access to network services.
The service parameter provides the name of a PAM service to use for authorization. It requires that a file /etc/pam.d/service exist to provide the configuration for the account subsystem.
An example authorization object to validate a TLS x509 distinguished name would look like:
# qemu-system-x86_64 \ ... \ -object authz-pam,id=auth0,service=qemu-vnc \ ...
There would then be a corresponding config file for PAM at /etc/pam.d/qemu-vnc that contains:
account requisite  pam_listfile.so item=user sense=allow \ file=/etc/qemu/vnc.allow
Finally the /etc/qemu/vnc.allow file would contain the list of x509 distingished names that are permitted access
CN=laptop.example.com,O=Example Home,L=London,ST=London,C=GB
-object iothread,id=id,poll-max-ns=poll-max-ns,poll-grow=poll-grow,poll-shrink=poll-shrink,aio-max-batch=aio-max-batch Creates a dedicated event loop thread that devices can be assigned to. This is known as an IOThread. By default device emulation happens in vCPU threads or the main event loop thread.  This can become a scalability bottleneck. IOThreads allow device emulation and I/O to run on other host CPUs.
The id parameter is a unique ID that will be used to reference this IOThread from -device ...,iothread=id. Multiple devices can be assigned to an IOThread. Note that not all devices support an iothread parameter.
The query-iothreads QMP command lists IOThreads and reports their thread IDs so that the user can configure host CPU pinning/affinity.
IOThreads use an adaptive polling algorithm to reduce event loop latency. Instead of entering a blocking system call to monitor file descriptors and then pay the cost of being woken up when an event occurs, the polling algorithm spins waiting for events for a short time. The algorithm's default parameters are suitable for many cases but can be adjusted based on knowledge of the workload and/or host device latency.
The poll-max-ns parameter is the maximum number of nanoseconds to busy wait for events. Polling can be disabled by setting this value to 0.
The poll-grow parameter is the multiplier used to increase the polling time when the algorithm detects it is missing events due to not polling long enough.
The poll-shrink parameter is the divisor used to decrease the polling time when the algorithm detects it is spending too long polling without encountering events.
The aio-max-batch parameter is the maximum number of requests in a batch for the AIO engine, 0 means that the engine will use its default.
The IOThread parameters can be modified at run-time using the qom-set command (where iothread1 is the IOThread's id):
(qemu) qom-set /objects/iothread1 poll-max-ns 100000
During the graphical emulation, you can use special key combinations to change modes. The default key mappings are shown below, but if you use -alt-grab then the modifier is Ctrl-Alt-Shift (instead of Ctrl-Alt) and if you use -ctrl-grab then the modifier is the right Ctrl key (instead of Ctrl-Alt):
Ctrl-Alt-f Toggle full screen
Ctrl-Alt-+ Enlarge the screen
Ctrl-Alt-- Shrink the screen
Ctrl-Alt-u Restore the screen's un-scaled dimensions
Ctrl-Alt-n Switch to virtual console 'n'. Standard console mappings are:
1      Target system display
2      Monitor
3      Serial port
Ctrl-Alt Toggle mouse and keyboard grab.
In the virtual consoles, you can use Ctrl-Up, Ctrl-Down, Ctrl-PageUp and Ctrl-PageDown to move in the back log.
During emulation, if you are using a character backend multiplexer (which is the default if you are using -nographic) then several commands are available via an escape sequence. These key sequences all start with an escape character, which is Ctrl-a by default, but can be changed with -echr. The list below assumes you're using the default.
Ctrl-a h Print this help
Ctrl-a x Exit emulator
Ctrl-a s Save disk data back to file (if -snapshot)
Ctrl-a t Toggle console timestamps
Ctrl-a b Send break (magic sysrq in Linux)
Ctrl-a c Rotate between the frontends connected to the multiplexer (usually this switches between the monitor and the console)
Ctrl-a Ctrl-a Send the escape character to the frontend
In addition to using normal file images for the emulated storage devices, QEMU can also use networked resources such as iSCSI devices.  These are specified using a special URL syntax.
iSCSI  iSCSI support allows QEMU to access iSCSI resources directly and use as images for the guest storage. Both disk and cdrom images are supported.
Syntax for specifying iSCSI LUNs is "iscsi://<target-ip>[:<port>]/<target-iqn>/<lun>"
By default qemu will use the iSCSI initiator-name 'iqn.2008-11.org.linux-kvm[:<name>]' but this can also be set from the command line or a configuration file.
Since version Qemu 2.4 it is possible to specify a iSCSI request timeout to detect stalled requests and force a reestablishment of the session. The timeout is specified in seconds. The default is 0 which means no timeout. Libiscsi 1.15.0 or greater is required for this feature.
Example (without authentication):
qemu-system-x86_64 -iscsi initiator-name=iqn.2001-04.com.example:my-initiator \ -cdrom iscsi://192.0.2.1/iqn.2001-04.com.example/2 \ -drive file=iscsi://192.0.2.1/iqn.2001-04.com.example/1
Example (CHAP username/password via URL):
qemu-system-x86_64 -drive file=iscsi://user%password@192.0.2.1/iqn.2001-04.com.example/1
Example (CHAP username/password via environment variables):
LIBISCSI_CHAP_USERNAME="user" \ LIBISCSI_CHAP_PASSWORD="password" \ qemu-system-x86_64 -drive file=iscsi://192.0.2.1/iqn.2001-04.com.example/1
NBD    QEMU supports NBD (Network Block Devices) both using TCP protocol as well as Unix Domain Sockets. With TCP, the default port is 10809.
Syntax for specifying a NBD device using TCP, in preferred URI form: "nbd://<server-ip>[:<port>]/[<export>]"
Syntax for specifying a NBD device using Unix Domain Sockets; remember that '?' is a shell glob character and may need quoting: "nbd+unix:///[<export>]?socket=<domain-socket>"
Older syntax that is also recognized: "nbd:<server-ip>:<port>[:exportname=<export>]"
Syntax for specifying a NBD device using Unix Domain Sockets "nbd:unix:<domain-socket>[:exportname=<export>]"
Example for TCP
qemu-system-x86_64 --drive file=nbd:192.0.2.1:30000
Example for Unix Domain Sockets
qemu-system-x86_64 --drive file=nbd:unix:/tmp/nbd-socket
SSH    QEMU supports SSH (Secure Shell) access to remote disks.
qemu-system-x86_64 -drive file=ssh://user@host/path/to/disk.img qemu-system-x86_64 -drive file.driver=ssh,file.user=user,file.host=host,file.port=22,file.path=/path/to/disk.img
Currently authentication must be done using ssh-agent. Other authentication methods may be supported in future.
GlusterFS GlusterFS is a user space distributed file system. QEMU supports the use of GlusterFS volumes for hosting VM disk images using TCP, Unix Domain Sockets and RDMA transport protocols.
Syntax for specifying a VM disk image on GlusterFS volume is
URI: gluster[+type]://[host[:port]]/volume/path[?socket=...][,debug=N][,logfile=...]
JSON: 'json:{"driver":"qcow2","file":{"driver":"gluster","volume":"testvol","path":"a.img","debug":N,"logfile":"...", "server":[{"type":"tcp","host":"...","port":"..."}, {"type":"unix","socket":"..."}]}}'
URI: qemu-system-x86_64 --drive file=gluster://192.0.2.1/testvol/a.img, file.debug=9,file.logfile=/var/log/qemu-gluster.log
JSON: qemu-system-x86_64 'json:{"driver":"qcow2", "file":{"driver":"gluster", "volume":"testvol","path":"a.img", "debug":9,"logfile":"/var/log/qemu-gluster.log", "server":[{"type":"tcp","host":"1.2.3.4","port":24007}, {"type":"unix","socket":"/var/run/glusterd.socket"}]}}' qemu-system-x86_64 -drive driver=qcow2,file.driver=gluster,file.volume=testvol,file.path=/path/a.img, file.debug=9,file.logfile=/var/log/qemu-gluster.log, file.server.0.type=tcp,file.server.0.host=1.2.3.4,file.server.0.port=24007, file.server.1.type=unix,file.server.1.socket=/var/run/glusterd.socket
See also http://www.gluster.org.
HTTP/HTTPS/FTP/FTPS QEMU supports read-only access to files accessed over http(s) and ftp(s).
Syntax using a single filename:
<protocol>://[<username>[:<password>]@]<host>/<path>
protocol 'http', 'https', 'ftp', or 'ftps'.
username Optional username for authentication to the remote server.
password Optional password for authentication to the remote server.
host   Address of the remote server.
path   Path on the remote server, including any query string.
The following options are also supported:
url    The full URL when passing options to the driver explicitly.
readahead The amount of data to read ahead with each range request to the remote server. This value may optionally have the suffix 'T', 'G', 'M', 'K', 'k' or 'b'. If it does not have a suffix, it will be assumed to be in bytes. The value must be a multiple of 512 bytes.  It defaults to 256k.
sslverify Whether to verify the remote server's certificate when connecting over SSL. It can have the value 'on' or 'off'. It defaults to 'on'.
cookie Send this cookie (it can also be a list of cookies separated by ';') with each outgoing request. Only supported when using protocols such as HTTP which support cookies, otherwise ignored.
timeout Set the timeout in seconds of the CURL connection. This timeout is the time that CURL waits for a response from the remote server to get the size of the image to be downloaded. If not set, the default timeout of 5 seconds is used.
Note that when passing options to qemu explicitly, driver is the value of <protocol>.
Example: boot from a remote Fedora 20 live ISO image
qemu-system-x86_64 --drive media=cdrom,file=https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/20/Live/x86_64/Fedora-Live-Desktop-x86_64-20-1.iso,readonly
qemu-system-x86_64 --drive media=cdrom,file.driver=http,file.url=http://archives.fedoraproject.org/pub/fedora/linux/releases/20/Live/x86_64/Fedora-Live-Desktop-x86_64-20-1.iso,readonly
Example: boot from a remote Fedora 20 cloud image using a local overlay for writes, copy-on-read, and a readahead of 64k
qemu-img create -f qcow2 -o backing_file='json:{"file.driver":"http",, "file.url":"http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/20/Images/x86_64/Fedora-x86_64-20-20131211.1-sda.qcow2",, "file.readahead":"64k"}' /tmp/Fedora-x86_64-20-20131211.1-sda.qcow2
qemu-system-x86_64 -drive file=/tmp/Fedora-x86_64-20-20131211.1-sda.qcow2,copy-on-read=on
Example: boot from an image stored on a VMware vSphere server with a self-signed certificate using a local overlay for writes, a readahead of 64k and a timeout of 10 seconds.
qemu-img create -f qcow2 -o backing_file='json:{"file.driver":"https",, "file.url":"https://user:password@vsphere.example.com/folder/test/test-flat.vmdk?dcPath=Datacenter&dsName=datastore1",, "file.sslverify":"off",, "file.readahead":"64k",, "file.timeout":10}' /tmp/test.qcow2
qemu-system-x86_64 -drive file=/tmp/test.qcow2
The HTML documentation of QEMU for more precise information and Linux user mode emulator invocation.
2021, The QEMU Project Developers
ETCDCTL(1)                        User Commands                       ETCDCTL(1)
etcdctl - A simple command line client for etcd.
Set environment variable ETCDCTL_API=3 to use v3 API or ETCDCTL_API=2 to use v2 API.
etcdctl [options] command [command options] [arguments...]
COMMANDS V3 alarm disarm Disarms all alarms
alarm list Lists all alarms
auth disable Disables authentication
auth enable Enables authentication
check perf Check the performance of the etcd cluster
compaction Compacts the event history in etcd
defrag Defragments the storage of the etcd members with given endpoints
del    Removes the specified key or range of keys [key, range_end)
elect  Observes and participates in leader election
endpoint hashkv Prints the KV history hash for each endpoint in --endpoints
endpoint health Checks the healthiness of endpoints specified in `--endpoints` flag
endpoint status Prints out the status of endpoints specified in `--endpoints` flag
get    Gets the key or a range of keys
help   Help about any command
lease grant Creates leases
lease keep-alive Keeps leases alive (renew)
lease list List all active leases
lease revoke Revokes leases
lease timetolive Get lease information
lock   Acquires a named lock
make-mirror Makes a mirror at the destination etcd cluster
member add Adds a member into the cluster
member list Lists all members in the cluster
member remove Removes a member from the cluster
member update Updates a member in the cluster
migrate Migrates keys in a v2 store to a mvcc store
move-leader Transfers leadership to another etcd cluster member.
put    Puts the given key into the store
role add Adds a new role
role delete Deletes a role
role get Gets detailed information of a role
role grant-permission Grants a key to a role
role list Lists all roles
role revoke-permission Revokes a key from a role
snapshot restore Restores an etcd member snapshot to an etcd directory
snapshot save Stores an etcd node backend snapshot to a given file
snapshot status Gets backend snapshot status of a given file
txn    Txn processes all the requests in one transaction
user add Adds a new user
user delete Deletes a user
user get Gets detailed information of a user
user grant-role Grants a role to a user
user list Lists all users
user passwd Changes password of user
user revoke-role Revokes a role from a user
version Prints the version of etcdctl
watch  Watches events stream on keys or prefixes
OPTIONS V3 --cacert="" verify certificates of TLS-enabled secure servers using this CA bundle
--cert="" identify secure client using this TLS certificate file
--command-timeout=5s timeout for short running command (excluding dial timeout)
--debug[=false] enable client-side debug logging
--dial-timeout=2s dial timeout for client connections
-d, --discovery-srv="" domain name to query for SRV records describing cluster endpoints
--endpoints=[127.0.0.1:2379] gRPC endpoints
-h, --help[=false] help for etcdctl
--hex[=false] print byte strings as hex encoded strings
--insecure-discovery[=true] accept insecure SRV records describing cluster endpoints
--insecure-skip-tls-verify[=false] skip server certificate verification (CAUTION: this option should be enabled only for testing purposes)
--insecure-transport[=true] disable transport security for client connections
--keepalive-time=2s keepalive time for client connections
--keepalive-timeout=6s keepalive timeout for client connections
--key="" identify secure client using this TLS key file
--user="" username[:password] for authentication (prompt if password is not supplied)
-w, --write-out="simple" set the output format (fields, json, protobuf, simple, table)
COMMANDS V2 backup backup an etcd directory
cluster-health check the health of the etcd cluster
mk     make a new key with a given value
mkdir  make a new directory
rm     remove a key or a directory
rmdir  removes the key if it is an empty directory or a key-value pair
get    retrieve the value of a key
ls     retrieve a directory
set    set the value of a key
setdir create a new directory or update an existing directory TTL
update update an existing key with a given value
updatedir update an existing directory
watch  watch a key for changes
exec-watch watch a key for changes and exec an executable
member member add, remove and list subcommands
user   user add, grant and revoke subcommands
role   role add, grant and revoke subcommands
auth   overall auth controls
help, h Shows a list of commands or help for one command
OPTIONS V2 --debug output cURL commands which can be used to reproduce the request
--no-sync don't synchronize cluster information before sending request
--output simple, -o simple output response in the given format (simple, `extended` or `json`) (default: "simple")
--discovery-srv value, -D value domain name to query for SRV records describing cluster endpoints
--insecure-discovery accept insecure SRV records describing cluster endpoints
--peers value, -C value DEPRECATED - "--endpoints" should be used instead
--endpoint value DEPRECATED - "--endpoints" should be used instead
--endpoints value a comma-delimited list of machine addresses in the cluster (default: "http://127.0.0.1:2379,http://127.0.0.1:4001")
--cert-file value identify HTTPS client using this SSL certificate file
--key-file value identify HTTPS client using this SSL key file
--ca-file value verify certificates of HTTPS-enabled servers using this CA bundle
--username value, -u value provide username[:password] and prompt if password is not supplied.
--timeout value connection timeout per request (default: 2s)
--total-timeout value timeout for the command execution (except watch) (default: 5s)
--help, -h show help
--version, -v print the version
ectd(1)
LSHW(1)                                                                  LSHW(1)
lshw - list hardware
lshw [ -version ]
lshw [ -help ]
lshw [ -X ]
lshw [  [ -html ]  [ -short ]  [ -xml ]  [ -json ]  [ -businfo ]  ]  [ -dump filename ]  [ -class class... ]  [ -disable test... ]  [ -enable test... ]  [ -sanitize ]  [ -numeric ]  [ -quiet ]
lshw is a small tool to extract detailed information on the hardware configuration of the machine. It can report exact memory configuration, firmware version, mainboard configuration, CPU version and speed, cache configuration, bus speed, etc. on DMI-capable x86 or IA-64 systems and on some PowerPC machines (PowerMac G4 is known to work).
It currently supports DMI (x86 and IA-64 only), OpenFirmware device tree (PowerPC only), PCI/AGP, CPUID (x86), IDE/ATA/ATAPI, PCMCIA (only tested on x86), SCSI and USB.
-version Displays the version of lshw and exits.
-help  Displays the available command line options and quits.
-X     Launch the X11 GUI (if available).
-html  Outputs the device tree as an HTML page.
-xml   Outputs the device tree as an XML tree.
-json  Outputs the device tree as a JSON object (JavaScript Object Notation).
-short Outputs the device tree showing hardware paths, very much like the output of HP-UX's ioscan.
-businfo Outputs the device list showing bus information, detailing SCSI, USB, IDE and PCI addresses.
-dump filename Display output and dump collected information into a file (SQLite database).
-class class Only show the given class of hardware. class can be found using lshw -short or lshw -businfo.
-C class Alias for -class class.
-enable test
-disable test Enables or disables a test. test can be dmi (for DMI/SMBIOS extensions), device-tree (for OpenFirmware device tree), spd (for memory Serial Presence Detect), memory (for memory-size guessing heuristics), cpuinfo (for kernel-reported CPU detection), cpuid (for CPU detection), pci (for PCI/AGP access), isapnp (for ISA PnP extensions), pcmcia (for PCMCIA/PCCARD), ide (for IDE/ATAPI), usb (for USB devices),scsi (for SCSI) or network (for network interfaces detection).
-quiet Don't display status.
-sanitize Remove potentially sensitive information from output (IP addresses, serial numbers, etc.).
-numeric Also display numeric IDs (for PCI and USB devices).
lshw currently does not detect Firewire(IEEE1394) devices.
Not all architectures supported by GNU/Linux are fully supported (e.g. CPU detection).
"Virtual" SCSI interfaces used for SCSI emulation over IDE are not reported correctly yet.
lshw must be run as super user or it will only report partial information.
/usr/local/share/pci.ids
/usr/share/pci.ids
/etc/pci.ids
/usr/share/hwdata/pci.ids A list of all known PCI ID's (vendors, devices, classes and subclasses).  If compiled with zlib support, lshw will look for pci.ids.gz first, then for pci.ids.
/proc/bus/pci/* Used to access the configuration of installed PCI buses and devices.
/proc/ide/* Used to access the configuration of installed IDE buses and devices.
/proc/scsi/*, /dev/sg* Used to access the configuration of installed SCSI devices.
/dev/cpu/*/cpuid Used on x86 platforms to access CPU-specific configuration.
/proc/device-tree/* Used on PowerPC platforms to access OpenFirmware configuration.
/proc/bus/usb/* Used to access the configuration of installed USB buses and devices.
/sys/* Used on 2.6 kernels to access hardware/driver configuration information.
lshw -short Lists hardware in a compact format.
lshw -class disk -class storage Lists all disks and storage controllers in the system.
lshw -html -class network Lists all network interfaces in HTML.
lshw -disable dmi Don't use DMI to detect hardware.
/proc/*, linuxinfo(1), lspci(8), lsusb(8)
lshw is distributed under the GNU GENERAL PUBLIC LICENSE (GPL) version 2.
lshw is maintained by Lyonel Vincent <lyonel@ezix.org>.
The webpage for lshw is at <URL:http://lshw.ezix.org/>
gh-browse - Open the repository in the browser
gh browse [<number> | <path>] [flags]
Open the GitHub repository in the web browser.
-b, --branch=""      Select another branch by passing in the branch name
-c, --commit[=false]      Open the last commit
-n, --no-browser[=false]      Print destination URL instead of opening the browser
-p, --projects[=false]      Open repository projects
-s, --settings[=false]      Open repository settings
-w, --wiki[=false]      Open repository wiki
$ gh browse #=> Open the home page of the current repository
$ gh browse 217 #=> Open issue or pull request 217
$ gh browse --settings #=> Open repository settings
$ gh browse main.go:312 #=> Open main.go at line 312
$ gh browse main.go --branch main #=> Open main.go in the main branch
gh(1)
LLVM-NM(1)                            LLVM                            LLVM-NM(1)
llvm-nm - list LLVM bitcode and object file's symbol table
llvm-nm [options] [filenames...]
The llvm-nm utility lists the names of symbols from LLVM bitcode files, object files, and archives. Each symbol is listed along with some simple information about its provenance. If no filename is specified, a.out is used as the input. If - is used as a filename, llvm-nm will read a file from its standard input stream.
llvm-nm's default output format is the traditional BSD nm output format. Each such output record consists of an (optional) 8-digit hexadecimal address, followed by a type code character, followed by a name, for each symbol. One record is printed per line; fields are separated by spaces. When the address is omitted, it is replaced by 8 spaces.
The supported type code characters are as follows. Where both lower and upper-case characters are listed for the same meaning, a lower-case character represents a local symbol, whilst an upper-case character represents a global (external) symbol:
a, A Absolute symbol.
b, B Uninitialized data (bss) object.
C Common symbol. Multiple definitions link together into one definition.
d, D Writable data object.
i, I COFF: .idata symbol or symbol in a section with IMAGE_SCN_LNK_INFO set.
n ELF: local symbol from non-alloc section.
COFF: debug symbol.
N ELF: debug section symbol, or global symbol from non-alloc section.
s, S COFF: section symbol.
Mach-O: absolute symbol or symbol from a section other than __TEXT_EXEC __text, __TEXT __text, __DATA __data, or __DATA __bss.
r, R Read-only data object.
t, T Code (text) object.
u ELF: GNU unique symbol.
U Named object is undefined in this file.
v ELF: Undefined weak object. It is not a link failure if the object is not defined.
V ELF: Defined weak object symbol. This definition will only be used if no regular definitions exist in a link. If multiple weak definitions and no regular definitions exist, one of the weak definitions will be used.