neulab/tldr huggingface dataset:
finally Warn about finally clauses that cannot complete normally. For example: public static int m() { try { throw new NullPointerException(); } catch (NullPointerException e) { System.err.println("Caught NullPointerException."); return 1; } finally { return 0; } } The compiler generates a warning for finally block in this example. When this method is called, it returns a value of 0, not 1. A finally block always executes when the try block exits. In this example, if control is transferred to the catch, then the method exits. However, the finally block must be executed, so it is executed, even though control has already been transferred outside the method.
options Warn about issues relating to the use of command line options. See Cross-Compilation Example for an example of this kind of warning.
overrides Warn about issues regarding method overrides. For example, consider the following two classes: public class ClassWithVarargsMethod { void varargsMethod(String... s) { } } public class ClassWithOverridingMethod extends ClassWithVarargsMethod { @Override void varargsMethod(String[] s) { } } The compiler generates a warning similar to the following: warning: [override] varargsMethod(String[]) in ClassWithOverridingMethod overrides varargsMethod(String...) in ClassWithVarargsMethod; overriding method is missing '...' When the compiler encounters a varargs method, it translates the varargs formal parameter into an array. In the method ClassWithVarargsMethod.varargsMethod, the compiler translates the varargs formal parameter String... s to the formal parameter String[] s, an array, which matches the formal parameter of the method ClassWithOverridingMethod.varargsMethod. Consequently, this example compiles.
path Warn about invalid path elements and nonexistent path directories on the command line (with regards to the class path, the source path, and other paths). Such warnings cannot be suppressed with the @SuppressWarnings annotation. For example: javac -Xlint:path -classpath /nonexistentpath Example.java
processing Warn about issues regarding annotation processing. The compiler generates this warning if you have a class that has an annotation, and you use an annotation processor that cannot handle that type of exception. For example, the following is a simple annotation processor: Source file AnnoProc.java: import java.util.*; import javax.annotation.processing.*; import javax.lang.model.*; import javax.lang.model.element.*;
@SupportedAnnotationTypes("NotAnno") public class AnnoProc extends AbstractProcessor { public boolean process(Set<? extends TypeElement> elems, RoundEnvironment renv) { return true; }
public SourceVersion getSupportedSourceVersion() { return SourceVersion.latest(); } } Source file AnnosWithoutProcessors.java: @interface Anno { }
@Anno class AnnosWithoutProcessors { } The following commands compile the annotation processor AnnoProc, then run this annotation processor against the source file AnnosWithoutProcessors.java: % javac AnnoProc.java % javac -cp . -Xlint:processing -processor AnnoProc -proc:only AnnosWithoutProcessors.java When the compiler runs the annotation processor against the source file AnnosWithoutProcessors.java, it generates the following warning: warning: [processing] No processor claimed any of these annotations: Anno To resolve this issue, you can rename the annotation defined and used in the class AnnosWithoutProcessors from Anno to NotAnno.
rawtypes Warn about unchecked operations on raw types. The following statement generates a rawtypes warning: void countElements(List l) { ... } The following does not generate a rawtypes warning: void countElements(List<?> l) { ... } List is a raw type. However, List<?> is a unbounded wildcard parameterized type. Because List is a parameterized interface, you should always specify its type argument. In this example, the List formal argument is specified with a unbounded wildcard (?) as its formal type parameter, which means that the countElements method can accept any instantiation of the List interface.
serial Warn about missing serialVersionUID definitions on serializable classes. For example: public class PersistentTime implements Serializable { private Date time;
public PersistentTime() { time = Calendar.getInstance().getTime(); }
public Date getTime() { return time; } } The compiler generates the following warning: warning: [serial] serializable class PersistentTime has no definition of serialVersionUID If a serializable class does not explicitly declare a field named serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values because the default process of computing serialVersionUID vales is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different Java compiler implementations, a serializable class must declare an explicit serialVersionUID value.
static Warn about issues relating to use of statics. For example: class XLintStatic { static void m1() { } void m2() { this.m1(); } } The compiler generates the following warning: warning: [static] static method should be qualified by type name, XLintStatic, instead of by an expression To resolve this issue, you can call the static method m1 as follows: XLintStatic.m1(); Alternatively, you can remove the static keyword from the declaration of the method m1.
try Warn about issues relating to use of try blocks, including try-with-resources statements. For example, a warning is generated for the following statement because the resource ac declared in the try statement is not used: try ( AutoCloseable ac = getResource() ) { // do nothing }
unchecked Give more detail for unchecked conversion warnings that are mandated by the Java Language Specification. For example: List l = new ArrayList<Number>(); List<String> ls = l;       // unchecked warning During type erasure, the types ArrayList<Number> and List<String> become ArrayList and List, respectively. The variable ls has the parameterized type List<String>. When the List referenced by l is assigned to ls, the compiler generates an unchecked warning; the compiler is unable to determine at compile time, and moreover knows that the JVM will not be able to determine at runtime, if l refers to a List<String> type; it does not. Consequently, heap pollution occurs. In detail, a heap pollution situation occurs when the List object l, whose static type is List<Number>, is assigned to another List object, ls, that has a different static type, List<String>. However, the compiler still allows this assignment. It must allow this assignment to preserve backwards compatibility with versions of Java SE that do not support generics. Because of type erasure, List<Number> and List<String> both become List. Consequently, the compiler allows the assignment of the object l, which has a raw type of List, to the object ls.
varargs Warn about unsafe usages of variable arguments (varargs) methods, in particular, those that contain non-reifiable arguments. For example: public class ArrayBuilder { public static <T> void addToList (List<T> listArg, T... elements) { for (T x : elements) { listArg.add(x); } } } The compiler generates the following warning for the definition of the method ArrayBuilder.addToList: warning: [varargs] Possible heap pollution from parameterized vararg type T When the compiler encounters a varargs method, it translates the varargs formal parameter into an array. However, the Java programming language does not permit the creation of arrays of parameterized types. In the method ArrayBuilder.addToList, the compiler translates the varargs formal parameter T... elements to the formal parameter T[] elements, an array. However, because of type erasure, the compiler converts the varargs formal parameter to Object[] elements. Consequently, there is a possibility of heap pollution.
To shorten or simplify the javac command line, you can specify one or more files that themselves contain arguments to the javac command (except -J options). This enables you to create javac commands of any length on any operating system.
An argument file can include javac options and source filenames in any combination. The arguments within a file can be space-separated or newline-separated. If a filename contains embedded spaces, put the whole filename in double quotes.
Filenames within an argument file are relative to the current directory, not the location of the argument file. Wildcards (*) are not allowed in these lists (such as for specifying *.java). Use of the '@' character to recursively interpret files is not supported. The -J options are not supported because they are passed to the launcher, which does not support argument files.
When executing javac, pass in the path and name of each argument file with the '@' leading character. When javac encounters an argument beginning with the character `@', it expands the contents of that file into the argument list.
Example - Single Arg File You could use a single argument file named "argfile" to hold all javac arguments:
% javac @argfile
This argument file could contain the contents of both files shown in the next example.
Example - Two Arg Files You can create two argument files -- one for the javac options and the other for the source filenames: (Notice the following lists have no line-continuation characters.)
Create a file named "options" containing:
-d classes -g -sourcepath /java/pubs/ws/1.3/src/share/classes
Create a file named "classes" containing:
MyClass1.java MyClass2.java MyClass3.java
You would then run javac with:
% javac @options @classes
Example - Arg Files with Paths The argument files can have paths, but any filenames inside the files are relative to the current working directory (not path1 or path2):
% javac @path1/options @path2/classes
javac provides direct support for annotation processing, superseding the need for the separate annotation processing tool, apt.
The API for annotation processors is defined in the javax.annotation.processing and javax.lang.model packages and subpackages.
Overview of annotation processing Unless annotation processing is disabled with the -proc:none option, the compiler searches for any annotation processors that are available. The search path can be specified with the -processorpath option; if it is not given, the user class path is used. Processors are located by means of service provider-configuration files named META-INF/services/javax.annotation.processing.Processor on the search path. Such files should contain the names of any annotation processors to be used, listed one per line. Alternatively, processors can be specified explicitly, using the -processor option.
After scanning the source files and classes on the command line to determine what annotations are present, the compiler queries the processors to determine what annotations they process. When a match is found, the processor will be invoked. A processor may "claim" the annotations it processes, in which case no further attempt is made to find any processors for those annotations. Once all annotations have been claimed, the compiler does not look for additional processors.
If any processors generate any new source files, another round of annotation processing will occur: any newly generated source files will be scanned, and the annotations processed as before. Any processors invoked on previous rounds will also be invoked on all subsequent rounds. This continues until no new source files are generated.
After a round occurs where no new source files are generated, the annotation processors will be invoked one last time, to give them a chance to complete any work they may need to do. Finally, unless the -proc:only option is used, the compiler will compile the original and all the generated source files.
Implicitly loaded source files To compile a set of source files, the compiler may need to implicitly load additional source files. (See Searching For Types). Such files are currently not subject to annotation processing. By default, the compiler will give a warning if annotation processing has occurred and any implicitly loaded source files are compiled. See the -implicit option for ways to suppress the warning.
When compiling a source file, the compiler often needs information about a type whose definition did not appear in the source files given on the command line. The compiler needs type information for every class or interface used, extended, or implemented in the source file. This includes classes and interfaces not explicitly mentioned in the source file but which provide information through inheritance.
For example, when you subclass java.applet.Applet, you are also using Applet's ancestor classes: java.awt.Panel, java.awt.Container, java.awt.Component, and java.lang.Object.
When the compiler needs type information, it looks for a source file or class file which defines the type. The compiler searches for class files first in the bootstrap and extension classes, then in the user class path (which by default is the current directory). The user class path is defined by setting the CLASSPATH environment variable or by using the -classpath command line option. (For details, see Setting the Class Path).
If you set the -sourcepath option, the compiler searches the indicated path for source files; otherwise the compiler searches the user class path for both class files and source files.
You can specify different bootstrap or extension classes with the -bootclasspath and -extdirs options; see Cross-Compilation Options below.
A successful type search may produce a class file, a source file, or both. If both are found, you can use the -Xprefer option to instruct the compiler which to use. If newer is given, the compiler will use the newer of the two files. If source is given, it will use the source file. The default is newer.
If a type search finds a source file for a required type, either by itself, or as a result of the setting for -Xprefer, the compiler will read the source file to get the information it needs. In addition, it will by default compile the source file as well. You can use the -implicit option to specify the behavior. If none is given, no class files will be generated for the source file. If class is given, class files will be generated for the source file.
The compiler may not discover the need for some type information until after annotation processing is complete. If the type information is found in a source file and no -implicit option is given, the compiler will give a warning that the file is being compiled without being subject to annotation processing. To disable the warning, either specify the file on the command line (so that it will be subject to annotation processing) or use the -implicit option to specify whether or not class files should be generated for such source files.
javac supports the new Java Compiler API defined by the classes and interfaces in the javax.tools package.
Example To perform a compilation using arguments as you would give on the command line, you can use the following:
JavaCompiler javac = ToolProvider.getSystemJavaCompiler(); int rc = javac.run(null, null, null, args);
This will write any diagnostics to the standard output stream, and return the exit code that javac would give when invoked from the command line.
You can use other methods on the javax.tools.JavaCompiler interface to handle diagnostics, control where files are read from and written to, and so on.
Old Interface Note: This API is retained for backwards compatibility only; all new code should use the Java Compiler API, described above.
The com.sun.tools.javac.Main class provides two static methods to invoke the compiler from a program:
public static int compile(String[] args); public static int compile(String[] args, PrintWriter out);
The args parameter represents any of the command line arguments that would normally be passed to the javac program and are outlined in the above Synopsis section.
The out parameter indicates where the compiler's diagnostic output is directed.
The return value is equivalent to the exit value from javac.
Note that all other classes and methods found in a package whose name starts with com.sun.tools.javac (informally known as sub-packages of com.sun.tools.javac) are strictly internal and subject to change at any time.
Compiling a Simple Program One source file, Hello.java, defines a class called greetings.Hello. The greetings directory is the package directory both for the source file and the class file and is off the current directory. This allows us to use the default user class path. It also makes it unnecessary to specify a separate destination directory with -d.
% ls greetings/ % ls greetings Hello.java % cat greetings/Hello.java package greetings;
public class Hello { public static void main(String[] args) { for (int i=0; i < args.length; i++) { System.out.println("Hello " + args[i]); } } } % javac greetings/Hello.java % ls greetings Hello.class   Hello.java % java greetings.Hello World Universe Everyone Hello World Hello Universe Hello Everyone
Compiling Multiple Source Files This example compiles all the source files in the package greetings.
% ls greetings/ % ls greetings Aloha.java         GutenTag.java      Hello.java         Hi.java % javac greetings/*.java % ls greetings Aloha.class         GutenTag.class      Hello.class         Hi.class Aloha.java          GutenTag.java       Hello.java          Hi.java
Specifying a User Class Path Having changed one of the source files in the previous example, we recompile it:
% pwd /examples % javac greetings/Hi.java
Since greetings.Hi refers to other classes in the greetings package, the compiler needs to find these other classes. The example above works, because our default user class path happens to be the directory containing the package directory. But suppose we want to recompile this file and not worry about which directory we're in? Then we need to add /examples to the user class path. We can do this by setting CLASSPATH, but here we'll use the -classpath option.
% javac -classpath /examples /examples/greetings/Hi.java
If we change greetings.Hi again, to use a banner utility, that utility also needs to be accessible through the user class path.
% javac -classpath /examples:/lib/Banners.jar \ /examples/greetings/Hi.java
To execute a class in greetings, we need access both to greetings and to the classes it uses.
% java -classpath /examples:/lib/Banners.jar greetings.Hi
Separating Source Files and Class Files It often makes sense to keep source files and class files in separate directories, especially on large projects. We use -d to indicate the separate class file destination. Since the source files are not in the user class path, we use -sourcepath to help the compiler find them.
% ls classes/  lib/      src/ % ls src farewells/ % ls src/farewells Base.java      GoodBye.java % ls lib Banners.jar % ls classes % javac -sourcepath src -classpath classes:lib/Banners.jar \ src/farewells/GoodBye.java -d classes % ls classes farewells/ % ls classes/farewells Base.class      GoodBye.class
Note: The compiler compiled src/farewells/Base.java, even though we didn't specify it on the command line. To trace automatic compiles, use the -verbose option.
Cross-Compilation Example The following example uses javac to compile code that will run on a 1.6 VM.
% javac -source 1.6 -target 1.6 -bootclasspath jdk1.6.0/lib/rt.jar \ -extdirs "" OldCode.java
The -source 1.6 option specifies that version 1.6 (or 6) of the Java programming language be used to compile OldCode.java. The option -target 1.6 option ensures that the generated class files will be compatible with 1.6 VMs. Note that in most cases, the value of the -target option is the value of the -source option; in this example, you can omit the -target option.
You must specify the -bootclasspath option to specify the correct version of the bootstrap classes (the rt.jar library). If not, the compiler generates a warning:
% javac -source 1.6 OldCode.java warning: [options] bootstrap class path not set in conjunction with -source 1.6
If you do not specify the correct version of bootstrap classes, the compiler will use the old language rules (in this example, it will use version 1.6 of the Java programming language) combined with the new bootstrap classes, which can result in class files that do not work on the older platform (in this case, Java SE 6) because reference to non-existent methods can get included.
o The javac Guide @ http://docs.oracle.com/javase/7/docs/technotes/guides/javac/index.html
o jdb(1) - Java Application Debugger
o javah(1) - C Header and Stub File Generator
o javap(1) - Class File Disassembler
o javadoc(1) - API Documentation Generator
o jar(1) - JAR Archive Tool
o The Java Extensions Framework @ http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/index.html
QEMU(1)                               QEMU                               QEMU(1)
qemu - QEMU User Documentation
qemu-system-x86_64 [options] [disk_image]
The QEMU PC System emulator simulates the following peripherals:
• i440FX host PCI bridge and PIIX3 PCI to ISA bridge
• Cirrus CLGD 5446 PCI VGA card or dummy VGA card with Bochs VESA extensions (hardware level, including all non standard modes).
• PS/2 mouse and keyboard
• 2 PCI IDE interfaces with hard disk and CD-ROM support
• Floppy disk
• PCI and ISA network adapters
• Serial ports
• IPMI BMC, either and internal or external one
• Creative SoundBlaster 16 sound card
• ENSONIQ AudioPCI ES1370 sound card
• Intel 82801AA AC97 Audio compatible sound card
• Intel HD Audio Controller and HDA codec
• Adlib (OPL2) - Yamaha YM3812 compatible chip
• Gravis Ultrasound GF1 sound card
• CS4231A compatible sound card
• PC speaker
• PCI UHCI, OHCI, EHCI or XHCI USB controller and a virtual USB-1.1 hub.
SMP is supported with up to 255 CPUs.
QEMU uses the PC BIOS from the Seabios project and the Plex86/Bochs LGPL VGA BIOS.
QEMU uses YM3812 emulation by Tatsuyuki Satoh.
QEMU uses GUS emulation (GUSEMU32 http://www.deinmeister.de/gusemu/) by Tibor "TS" Schütz.
Note that, by default, GUS shares IRQ(7) with parallel ports and so QEMU must be told to not have parallel ports to have working GUS.
qemu-system-x86_64 dos.img -device gus -parallel none
qemu-system-x86_64 dos.img -device gus,irq=5
Or some other unclaimed IRQ.
CS4231A is the chip used in Windows Sound System and GUSMAX products
The PC speaker audio device can be configured using the pcspk-audiodev machine property, i.e.
qemu-system-x86_64 some.img -audiodev <backend>,id=<name> -machine pcspk-audiodev=<name>
disk_image is a raw hard disk image for IDE hard disk 0. Some targets do not need a disk image.
Standard options -h     Display help and exit
-version Display version information and exit
-machine [type=]name[,prop=value[,...]] Select the emulated machine by name. Use -machine help to list available machines.
For architectures which aim to support live migration compatibility across releases, each release will introduce a new versioned machine type. For example, the 2.8.0 release introduced machine types "pc-i440fx-2.8" and "pc-q35-2.8" for the x86_64/i686 architectures.
To allow live migration of guests from QEMU version 2.8.0, to QEMU version 2.9.0, the 2.9.0 version must support the "pc-i440fx-2.8" and "pc-q35-2.8" machines too. To allow users live migrating VMs to skip multiple intermediate releases when upgrading, new releases of QEMU will support machine types from many previous versions.
Supported machine properties are:
accel=accels1[:accels2[:...]] This is used to enable an accelerator. Depending on the target architecture, kvm, xen, hax, hvf, nvmm, whpx or tcg can be available.  By default, tcg is used. If there is more than one accelerator specified, the next one is used if the previous one fails to initialize.
vmport=on|off|auto Enables emulation of VMWare IO port, for vmmouse etc. auto says to select the value based on accel. For accel=xen the default is off otherwise the default is on.
dump-guest-core=on|off Include guest memory in a core dump. The default is on.
mem-merge=on|off Enables or disables memory merge support. This feature, when supported by the host, de-duplicates identical memory pages among VMs instances (enabled by default).
aes-key-wrap=on|off Enables or disables AES key wrapping support on s390-ccw hosts.  This feature controls whether AES wrapping keys will be created to allow execution of AES cryptographic functions. The default is on.
dea-key-wrap=on|off Enables or disables DEA key wrapping support on s390-ccw hosts.  This feature controls whether DEA wrapping keys will be created to allow execution of DEA cryptographic functions. The default is on.
nvdimm=on|off Enables or disables NVDIMM support. The default is off.
memory-encryption= Memory encryption object to use. The default is none.
hmat=on|off Enables or disables ACPI Heterogeneous Memory Attribute Table (HMAT) support. The default is off.
memory-backend='id' An alternative to legacy -mem-path and mem-prealloc options.  Allows to use a memory backend as main RAM.
-object memory-backend-file,id=pc.ram,size=512M,mem-path=/hugetlbfs,prealloc=on,share=on -machine memory-backend=pc.ram -m 512M
Migration compatibility note:
• as backend id one shall use value of 'default-ram-id', advertised by machine type (available via query-machines QMP command), if migration to/from old QEMU (<5.0) is expected.
• for machine types 4.0 and older, user shall use x-use-canonical-path-for-ramblock-id=off backend option if migration to/from old QEMU (<5.0) is expected.
-object memory-backend-ram,id=pc.ram,size=512M,x-use-canonical-path-for-ramblock-id=off -machine memory-backend=pc.ram -m 512M
-cpu model Select CPU model (-cpu help for list and additional feature selection)
-accel name[,prop=value[,...]] This is used to enable an accelerator. Depending on the target architecture, kvm, xen, hax, hvf, nvmm, whpx or tcg can be available. By default, tcg is used. If there is more than one accelerator specified, the next one is used if the previous one fails to initialize.
igd-passthru=on|off When Xen is in use, this option controls whether Intel integrated graphics devices can be passed through to the guest (default=off)
kernel-irqchip=on|off|split Controls KVM in-kernel irqchip support. The default is full acceleration of the interrupt controllers. On x86, split irqchip reduces the kernel attack surface, at a performance cost for non-MSI interrupts. Disabling the in-kernel irqchip completely is not recommended except for debugging purposes.
kvm-shadow-mem=size Defines the size of the KVM shadow MMU.
split-wx=on|off Controls the use of split w^x mapping for the TCG code generation buffer. Some operating systems require this to be enabled, and in such a case this will default on. On other operating systems, this will default off, but one may enable this for testing or debugging.
tb-size=n Controls the size (in MiB) of the TCG translation block cache.
thread=single|multi Controls number of TCG threads. When the TCG is multi-threaded there will be one thread per vCPU therefore taking advantage of additional host cores. The default is to enable multi-threading where both the back-end and front-ends support it and no incompatible TCG features have been enabled (e.g.  icount/replay).
dirty-ring-size=n When the KVM accelerator is used, it controls the size of the per-vCPU dirty page ring buffer (number of entries for each vCPU). It should be a value that is power of two, and it should be 1024 or bigger (but still less than the maximum value that the kernel supports).  4096 could be a good initial value if you have no idea which is the best. Set this value to 0 to disable the feature.  By default, this feature is disabled (dirty-ring-size=0).  When enabled, KVM will instead record dirty pages in a bitmap.
-smp [[cpus=]n][,maxcpus=maxcpus][,sockets=sockets][,dies=dies][,cores=cores][,threads=threads] Simulate a SMP system with 'n' CPUs initially present on the machine type board. On boards supporting CPU hotplug, the optional 'maxcpus' parameter can be set to enable further CPUs to be added at runtime. If omitted the maximum number of CPUs will be set to match the initial CPU count. Both parameters are subject to an upper limit that is determined by the specific machine type chosen.
To control reporting of CPU topology information, the number of sockets, dies per socket, cores per die, and threads per core can be specified.  The sum `` sockets * cores * dies * threads `` must be equal to the maximum CPU count. CPU targets may only support a subset of the topology parameters. Where a CPU target does not support use of a particular topology parameter, its value should be assumed to be 1 for the purpose of computing the CPU maximum count.
Either the initial CPU count, or at least one of the topology parameters must be specified. Values for any omitted parameters will be computed from those which are given. Historically preference was given to the coarsest topology parameters when computing missing values (ie sockets preferred over cores, which were preferred over threads), however, this behaviour is considered liable to change.
-numa node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=initiator]
-numa node[,memdev=id][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=initiator]
-numa dist,src=source,dst=destination,val=distance
-numa cpu,node-id=node[,socket-id=x][,core-id=y][,thread-id=z]
-numa hmat-lb,initiator=node,target=node,hierarchy=hierarchy,data-type=tpye[,latency=lat][,bandwidth=bw]
-numa hmat-cache,node-id=node,size=size,level=level[,associativity=str][,policy=str][,line=size] Define a NUMA node and assign RAM and VCPUs to it. Set the NUMA distance from a source node to a destination node. Set the ACPI Heterogeneous Memory Attributes for the given nodes.
Legacy VCPU assignment uses 'cpus' option where firstcpu and lastcpu are CPU indexes. Each 'cpus' option represent a contiguous range of CPU indexes (or a single VCPU if lastcpu is omitted). A non-contiguous set of VCPUs can be represented by providing multiple 'cpus' options. If 'cpus' is omitted on all nodes, VCPUs are automatically split between them.
For example, the following option assigns VCPUs 0, 1, 2 and 5 to a NUMA node:
-numa node,cpus=0-2,cpus=5
'cpu' option is a new alternative to 'cpus' option which uses 'socket-id|core-id|thread-id' properties to assign CPU objects to a node using topology layout properties of CPU. The set of properties is machine specific, and depends on used machine type/'smp' options. It could be queried with 'hotpluggable-cpus' monitor command. 'node-id' property specifies node to which CPU object will be assigned, it's required for node to be declared with 'node' option before it's used with 'cpu' option.
-M pc \ -smp 1,sockets=2,maxcpus=2 \ -numa node,nodeid=0 -numa node,nodeid=1 \ -numa cpu,node-id=0,socket-id=0 -numa cpu,node-id=1,socket-id=1
Legacy 'mem' assigns a given RAM amount to a node (not supported for 5.1 and newer machine types). 'memdev' assigns RAM from a given memory backend device to a node. If 'mem' and 'memdev' are omitted in all nodes, RAM is split equally between them.
'mem' and 'memdev' are mutually exclusive.  Furthermore, if one node uses 'memdev', all of them have to use it.
'initiator' is an additional option that points to an initiator NUMA node that has best performance (the lowest latency or largest bandwidth) to this NUMA node. Note that this option can be set only when the machine property 'hmat' is set to 'on'.
Following example creates a machine with 2 NUMA nodes, node 0 has CPU. node 1 has only memory, and its initiator is node 0. Note that because node 0 has CPU, by default the initiator of node 0 is itself and must be itself.
-machine hmat=on \ -m 2G,slots=2,maxmem=4G \ -object memory-backend-ram,size=1G,id=m0 \ -object memory-backend-ram,size=1G,id=m1 \ -numa node,nodeid=0,memdev=m0 \ -numa node,nodeid=1,memdev=m1,initiator=0 \ -smp 2,sockets=2,maxcpus=2  \ -numa cpu,node-id=0,socket-id=0 \ -numa cpu,node-id=0,socket-id=1
source and destination are NUMA node IDs. distance is the NUMA distance from source to destination. The distance from a node to itself is always 10. If any pair of nodes is given a distance, then all pairs must be given distances. Although, when distances are only given in one direction for each pair of nodes, then the distances in the opposite directions are assumed to be the same. If, however, an asymmetrical pair of distances is given for even one node pair, then all node pairs must be provided distance values for both directions, even when they are symmetrical. When a node is unreachable from another node, set the pair's distance to 255.
Note that the -numa option doesn't allocate any of the specified resources, it just assigns existing resources to NUMA nodes. This means that one still has to use the -m, -smp options to allocate RAM and VCPUs respectively.
Use 'hmat-lb' to set System Locality Latency and Bandwidth Information between initiator and target NUMA nodes in ACPI Heterogeneous Attribute Memory Table (HMAT). Initiator NUMA node can create memory requests, usually it has one or more processors. Target NUMA node contains addressable memory.
In 'hmat-lb' option, node are NUMA node IDs. hierarchy is the memory hierarchy of the target NUMA node: if hierarchy is 'memory', the structure represents the memory performance; if hierarchy is 'first-level|second-level|third-level', this structure represents aggregated performance of memory side caches for each domain. type of 'data-type' is type of data represented by this structure instance: if 'hierarchy' is 'memory', 'data-type' is 'access|read|write' latency or 'access|read|write' bandwidth of the target memory; if 'hierarchy' is 'first-level|second-level|third-level', 'data-type' is 'access|read|write' hit latency or 'access|read|write' hit bandwidth of the target memory side cache.
lat is latency value in nanoseconds. bw is bandwidth value, the possible value and units are NUM[M|G|T], mean that the bandwidth value are NUM byte per second (or MB/s, GB/s or TB/s depending on used suffix). Note that if latency or bandwidth value is 0, means the corresponding latency or bandwidth information is not provided.
In 'hmat-cache' option, node-id is the NUMA-id of the memory belongs. size is the size of memory side cache in bytes. level is the cache level described in this structure, note that the cache level 0 should not be used with 'hmat-cache' option. associativity is the cache associativity, the possible value is 'none/direct(direct-mapped)/complex(complex cache indexing)'. policy is the write policy. line is the cache Line size in bytes.
For example, the following options describe 2 NUMA nodes. Node 0 has 2 cpus and a ram, node 1 has only a ram. The processors in node 0 access memory in node 0 with access-latency 5 nanoseconds, access-bandwidth is 200 MB/s; The processors in NUMA node 0 access memory in NUMA node 1 with access-latency 10 nanoseconds, access-bandwidth is 100 MB/s. And for memory side cache information, NUMA node 0 and 1 both have 1 level memory cache, size is 10KB, policy is write-back, the cache Line size is 8 bytes:
-machine hmat=on \ -m 2G \ -object memory-backend-ram,size=1G,id=m0 \ -object memory-backend-ram,size=1G,id=m1 \ -smp 2 \ -numa node,nodeid=0,memdev=m0 \ -numa node,nodeid=1,memdev=m1,initiator=0 \ -numa cpu,node-id=0,socket-id=0 \ -numa cpu,node-id=0,socket-id=1 \ -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=5 \ -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \ -numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,latency=10 \ -numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=100M \ -numa hmat-cache,node-id=0,size=10K,level=1,associativity=direct,policy=write-back,line=8 \ -numa hmat-cache,node-id=1,size=10K,level=1,associativity=direct,policy=write-back,line=8
-add-fd fd=fd,set=set[,opaque=opaque] Add a file descriptor to an fd set. Valid options are:
fd=fd  This option defines the file descriptor of which a duplicate is added to fd set. The file descriptor cannot be stdin, stdout, or stderr.
set=set This option defines the ID of the fd set to add the file descriptor to.
opaque=opaque This option defines a free-form string that can be used to describe fd.
You can open an image using pre-opened file descriptors from an fd set:
qemu-system-x86_64 \ -add-fd fd=3,set=2,opaque="rdwr:/path/to/file" \ -add-fd fd=4,set=2,opaque="rdonly:/path/to/file" \ -drive file=/dev/fdset/2,index=0,media=disk
-set group.id.arg=value Set parameter arg for item id of type group
-global driver.prop=value
-global driver=driver,property=property,value=value Set default value of driver's property prop to value, e.g.:
qemu-system-x86_64 -global ide-hd.physical_block_size=4096 disk-image.img
In particular, you can use this to set driver properties for devices which are created automatically by the machine model. To create a device which is not created automatically and set properties on it, use -device.
-global driver.prop=value is shorthand for -global driver=driver,property=prop,value=value. The longhand syntax works even when driver contains a dot.
-boot [order=drives][,once=drives][,menu=on|off][,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_timeout][,strict=on|off] Specify boot order drives as a string of drive letters. Valid drive letters depend on the target architecture. The x86 PC uses: a, b (floppy 1 and 2), c (first hard disk), d (first CD-ROM), n-p (Etherboot from network adapter 1-4), hard disk boot is the default.  To apply a particular boot order only on the first startup, specify it via once. Note that the order or once parameter should not be used together with the bootindex property of devices, since the firmware implementations normally do not support both at the same time.
Interactive boot menus/prompts can be enabled via menu=on as far as firmware/BIOS supports them. The default is non-interactive boot.
A splash picture could be passed to bios, enabling user to show it as logo, when option splash=sp_name is given and menu=on, If firmware/BIOS supports them. Currently Seabios for X86 system support it. limitation: The splash file could be a jpeg file or a BMP file in 24 BPP format(true color). The resolution should be supported by the SVGA mode, so the recommended is 320x240, 640x480, 800x640.
A timeout could be passed to bios, guest will pause for rb_timeout ms when boot failed, then reboot. If rb_timeout is '-1', guest will not reboot, qemu passes '-1' to bios by default. Currently Seabios for X86 system support it.
Do strict boot via strict=on as far as firmware/BIOS supports it. This only effects when boot priority is changed by bootindex options. The default is non-strict boot.
# try to boot from network first, then from hard disk qemu-system-x86_64 -boot order=nc # boot from CD-ROM first, switch back to default order after reboot qemu-system-x86_64 -boot once=d # boot with a splash picture for 5 seconds. qemu-system-x86_64 -boot menu=on,splash=/root/boot.bmp,splash-time=5000
Note: The legacy format '-boot drives' is still supported but its use is discouraged as it may be removed from future versions.
-m [size=]megs[,slots=n,maxmem=size] Sets guest startup RAM size to megs megabytes. Default is 128 MiB. Optionally, a suffix of "M" or "G" can be used to signify a value in megabytes or gigabytes respectively. Optional pair slots, maxmem could be used to set amount of hotpluggable memory slots and maximum amount of memory. Note that maxmem must be aligned to the page size.
For example, the following command-line sets the guest startup RAM size to 1GB, creates 3 slots to hotplug additional memory and sets the maximum memory the guest can reach to 4GB:
qemu-system-x86_64 -m 1G,slots=3,maxmem=4G
If slots and maxmem are not specified, memory hotplug won't be enabled and the guest startup RAM will never increase.
-mem-path path Allocate guest RAM from a temporarily created file in path.
-mem-prealloc Preallocate memory when using -mem-path.
-k language Use keyboard layout language (for example fr for French). This option is only needed where it is not easy to get raw PC keycodes (e.g. on Macs, with some X11 servers or with a VNC or curses display). You don't normally need to use it on PC/Linux or PC/Windows hosts.
The available layouts are:
ar  de-ch  es  fo     fr-ca  hu  ja  mk     no  pt-br  sv da  en-gb  et  fr     fr-ch  is  lt  nl     pl  ru     th de  en-us  fi  fr-be  hr     it  lv  nl-be  pt  sl     tr
The default is en-us.
-audio-help Will show the -audiodev equivalent of the currently specified (deprecated) environment variables.
-audiodev [driver=]driver,id=id[,prop[=value][,...]] Adds a new audio backend driver identified by id. There are global and driver specific properties. Some values can be set differently for input and output, they're marked with in|out.. You can set the input's property with in.prop and the output's property with out.prop. For example:
-audiodev alsa,id=example,in.frequency=44110,out.frequency=8000 -audiodev alsa,id=example,out.channels=1 # leaves in.channels unspecified
NOTE: parameter validation is known to be incomplete, in many cases specifying an invalid option causes QEMU to print an error message and continue emulation without sound.
Valid global options are:
id=identifier Identifies the audio backend.
timer-period=period Sets the timer period used by the audio subsystem in microseconds. Default is 10000 (10 ms).
in|out.mixing-engine=on|off Use QEMU's mixing engine to mix all streams inside QEMU and convert audio formats when not supported by the backend. When off, fixed-settings must be off too. Note that disabling this option means that the selected backend must support multiple streams and the audio formats used by the virtual cards, otherwise you'll get no sound. It's not recommended to disable this option unless you want to use 5.1 or 7.1 audio, as mixing engine only supports mono and stereo audio. Default is on.
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 frequency, channels or format. Default is on.
in|out.frequency=frequency Specify the frequency to use when using fixed-settings. Default is 44100Hz.
in|out.channels=channels Specify the number of channels to use when using fixed-settings.  Default is 2 (stereo).
in|out.format=format Specify the sample format to use when using fixed-settings. Valid values are: s8, s16, s32, u8, u16, u32, f32. Default is s16.
in|out.voices=voices Specify the number of voices to use. Default is 1.
in|out.buffer-length=usecs Sets the size of the buffer in microseconds.
-audiodev none,id=id[,prop[=value][,...]] Creates a dummy backend that discards all outputs. This backend has no backend specific properties.
-audiodev alsa,id=id[,prop[=value][,...]] Creates backend using the ALSA. This backend is only available on Linux.
ALSA specific options are:
in|out.dev=device Specify the ALSA device to use for input and/or output. Default is default.
in|out.period-length=usecs Sets the period length in microseconds.
in|out.try-poll=on|off Attempt to use poll mode with the device. Default is on.
threshold=threshold Threshold (in microseconds) when playback starts. Default is 0.
-audiodev coreaudio,id=id[,prop[=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:
in|out.buffer-count=count Sets the count of the buffers.
-audiodev dsound,id=id[,prop[=value][,...]] Creates a backend using Microsoft's DirectSound. This backend is only available on Windows and only supports playback.
DirectSound specific options are:
latency=usecs Add extra usecs microseconds latency to playback. Default is 10000 (10 ms).
-audiodev oss,id=id[,prop[=value][,...]] Creates a backend using OSS. This backend is available on most Unix-like systems.
OSS specific options are:
in|out.dev=device Specify the file name of the OSS device to use. Default is /dev/dsp.
in|out.try-poll=on|of Attempt to use poll mode with the device. Default is on.
try-mmap=on|off Try using memory mapped device access. Default is off.
exclusive=on|off Open the device in exclusive mode (vmix won't work in this case). Default is off.
dsp-policy=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 buffer and buffer-count. This option is ignored if you do not have OSS 4. Default is 5.
-audiodev pa,id=id[,prop[=value][,...]] Creates a backend using PulseAudio. This backend is available on most systems.
PulseAudio specific options are:
server=server Sets the PulseAudio server to connect to.
in|out.name=sink Use the specified source/sink for recording/playback.
in|out.latency=usecs Desired latency in microseconds. The PulseAudio server will try to honor this value but actual latencies may be lower or higher.
-audiodev sdl,id=id[,prop[=value][,...]] Creates a backend using SDL. This backend is available on most systems, but you should use your platform's native backend if possible.
SDL specific options are:
-audiodev spice,id=id[,prop[=value][,...]] Creates a backend that sends audio through SPICE. This backend requires -spice and automatically selected in that case, so usually you can ignore this option. This backend has no backend specific properties.
-audiodev wav,id=id[,prop[=value][,...]] Creates a backend that writes audio to a WAV file.
Backend specific options are:
path=path Write recorded audio into the specified file. Default is qemu.wav.
-soundhw card1[,card2,...] or -soundhw all Enable audio and selected sound hardware. Use 'help' to print all available sound hardware. For example:
qemu-system-x86_64 -soundhw sb16,adlib disk.img qemu-system-x86_64 -soundhw es1370 disk.img qemu-system-x86_64 -soundhw ac97 disk.img qemu-system-x86_64 -soundhw hda disk.img qemu-system-x86_64 -soundhw all disk.img qemu-system-x86_64 -soundhw help
Note that Linux's i810_audio OSS kernel (for AC97) module might require manually specifying clocking.
modprobe i810_audio clocking=48000
-device driver[,prop[=value][,...]] Add device driver. prop=value sets driver properties. Valid properties depend on the driver. To get help on possible drivers and properties, use -device help and -device driver,help.
Some drivers are:
-device ipmi-bmc-sim,id=id[,prop[=value][,...]] Add an IPMI BMC. This is a simulation of a hardware management interface processor that normally sits on a system. It provides a watchdog and the ability to reset and power control the system. You need to connect this to an IPMI interface to make it useful
The IPMI slave address to use for the BMC. The default is 0x20. This address is the BMC's address on the I2C network of management controllers. If you don't know what this means, it is safe to ignore it.
id=id  The BMC id for interfaces to use this device.
slave_addr=val Define slave address to use for the BMC. The default is 0x20.
sdrfile=file file containing raw Sensor Data Records (SDR) data. The default is none.
fruareasize=val size of a Field Replaceable Unit (FRU) area. The default is 1024.
frudatafile=file file containing raw Field Replaceable Unit (FRU) inventory data.  The default is none.
guid=uuid value for the GUID for the BMC, in standard UUID format. If this is set, get "Get GUID" command to the BMC will return it.  Otherwise "Get GUID" will return an error.
-device ipmi-bmc-extern,id=id,chardev=id[,slave_addr=val] Add a connection to an external IPMI BMC simulator. Instead of locally emulating the BMC like the above item, instead connect to an external entity that provides the IPMI services.
A connection is made to an external BMC simulator. If you do this, it is strongly recommended that you use the "reconnect=" chardev option to reconnect to the simulator if the connection is lost. Note that if this is not used carefully, it can be a security issue, as the interface has the ability to send resets, NMIs, and power off the VM. It's best if QEMU makes a connection to an external simulator running on a secure port on localhost, so neither the simulator nor QEMU is exposed to any outside network.
See the "lanserv/README.vm" file in the OpenIPMI library for more details on the external interface.