aboutsummaryrefslogtreecommitdiff
path: root/qemu-options.hx
AgeCommit message (Collapse)AuthorFilesLines
2022-03-22qemu-options: define -spice only #ifdef CONFIG_SPICEMarc-André Lureau1-0/+2
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1982600 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2022-03-15ui/cocoa: add option to swap Option and CommandGustavo Noronha Silva1-1/+1
On Mac OS X the Option key maps to Alt and Command to Super/Meta. This change swaps them around so that Alt is the key closer to the space bar and Meta/Super is between Control and Alt, like on non-Mac keyboards. It is a cocoa display option, disabled by default. Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Gustavo Noronha Silva <gustavo@noronha.dev.br> Message-Id: <20210713213200.2547-3-gustavo@noronha.dev.br> Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com> Message-Id: <20220306121119.45631-3-akihiko.odaki@gmail.com> Reviewed-by: Will Cohen <wwcohen@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-03-15ui/cocoa: capture all keys and combos when mouse is grabbedGustavo Noronha Silva1-0/+3
Applications such as Gnome may use Alt-Tab and Super-Tab for different purposes, some use Ctrl-arrows so we want to allow qemu to handle everything when it captures the mouse/keyboard. However, Mac OS handles some combos like Command-Tab and Ctrl-arrows at an earlier part of the event handling chain, not letting qemu see it. We add a global Event Tap that allows qemu to see all events when the mouse is grabbed. Note that this requires additional permissions. See: https://developer.apple.com/documentation/coregraphics/1454426-cgeventtapcreate?language=objc#discussion https://support.apple.com/en-in/guide/mac-help/mh32356/mac Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Gustavo Noronha Silva <gustavo@noronha.dev.br> Message-Id: <20210713213200.2547-2-gustavo@noronha.dev.br> Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com> Message-Id: <20220306121119.45631-2-akihiko.odaki@gmail.com> Reviewed-by: Will Cohen <wwcohen@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-03-15ui/cocoa: add option to disable left-command forwarding to guestCarwyn Ellis1-0/+12
When switching between guest and host on a Mac using command-tab the command key is sent to the guest which can trigger functionality in the guest OS. Specifying left-command-key=off disables forwarding this key to the guest. Defaults to enabled. Also updated the cocoa display documentation to reference the new left-command-key option along with the existing show-cursor option. Signed-off-by: Carwyn Ellis <carwynellis@gmail.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@gmail.com> [PMD: Set QAPI structure @since tag to 7.0] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-03-06hw/smbios: Add table 4 parameter, "processor-id"Patrick Venture1-1/+2
This parameter is to be used in the processor_id entry in the type 4 table. This parameter is set as optional and if left will use the values from the CPU model. This enables hiding the host information from the guest and allowing AMD VMs to run pretending to be Intel for some userspace software concerns. Reviewed-by: Peter Foley <pefoley@google.com> Reviewed-by: Titus Rwantare <titusr@google.com> Signed-off-by: Patrick Venture <venture@google.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220125163118.1011809-1-venture@google.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-02-22qemu-options: fix incorrect description for '-drive index='Laurent Vivier1-1/+1
qemu-options.hx contains grammar that a native English-speaking person would never use. Replace "This option defines where is connected the drive" by "This option defines where the drive is connected". Fixes: https://gitlab.com/qemu-project/qemu/-/issues/853 Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20220202143422.912070-1-lvivier@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-01-20hw/arm/virt: Support CPU cluster on ARM virt machineYanan Wang1-0/+10
ARM64 machines like Kunpeng Family Server Chips have a level of hardware topology in which a group of CPU cores share L3 cache tag or L2 cache. For example, Kunpeng 920 typically has 6 or 8 clusters in each NUMA node (also represent range of CPU die), and each cluster has 4 CPU cores. All clusters share L3 cache data, but CPU cores in each cluster share a local L3 tag. Running a guest kernel with Cluster-Aware Scheduling on the Hosts which have physical clusters, if we can design a vCPU topology with cluster level for guest kernel and then have a dedicated vCPU pinning, the guest will gain scheduling performance improvement from cache affinity of CPU cluster. So let's enable the support for this new parameter on ARM virt machines. After this patch, we can define a 4-level CPU hierarchy like: cpus=*,maxcpus=*,sockets=*,clusters=*, cores=*,threads=*. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 20220107083232.16256-2-wangyanan55@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-05qemu-options: Remove the deprecated -no-quit optionThomas Huth1-8/+0
This option was just a wrapper around the -display ...,window-close=off parameter, and the name "no-quit" is rather confusing compared to "window-close" (since there are still other means to quit the emulator), so let's remove this now. Message-Id: <20211215082417.180735-1-thuth@redhat.com> Acked-by: Michal Prívozník <mprivozn@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-12-31hw/core/machine: Introduce CPU cluster topology supportYanan Wang1-3/+4
The new Cluster-Aware Scheduling support has landed in Linux 5.16, which has been proved to benefit the scheduling performance (e.g. load balance and wake_affine strategy) on both x86_64 and AArch64. So now in Linux 5.16 we have four-level arch-neutral CPU topology definition like below and a new scheduler level for clusters. struct cpu_topology { int thread_id; int core_id; int cluster_id; int package_id; int llc_id; cpumask_t thread_sibling; cpumask_t core_sibling; cpumask_t cluster_sibling; cpumask_t llc_sibling; } A cluster generally means a group of CPU cores which share L2 cache or other mid-level resources, and it is the shared resources that is used to improve scheduler's behavior. From the point of view of the size range, it's between CPU die and CPU core. For example, on some ARM64 Kunpeng servers, we have 6 clusters in each NUMA node, and 4 CPU cores in each cluster. The 4 CPU cores share a separate L2 cache and a L3 cache tag, which brings cache affinity advantage. In virtualization, on the Hosts which have pClusters (physical clusters), if we can design a vCPU topology with cluster level for guest kernel and have a dedicated vCPU pinning. A Cluster-Aware Guest kernel can also make use of the cache affinity of CPU clusters to gain similar scheduling performance. This patch adds infrastructure for CPU cluster level topology configuration and parsing, so that the user can specify cluster parameter if their machines support it. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Message-Id: <20211228092221.21068-3-wangyanan55@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> [PMD: Added '(since 7.0)' to @clusters in qapi/machine.json] Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-12-31qemu-options: Improve readability of SMP related DocsYanan Wang1-17/+59
We have a description in qemu-options.hx for each CPU topology parameter to explain what it exactly means, and also an extra declaration for the target-specific one, e.g. "for PC only" when describing "dies", and "for PC, it's on one die" when describing "cores". Now we are going to introduce one more non-generic parameter "clusters", it will make the Doc less readable and if we still continue to use the legacy way to describe it. So let's at first make two tweaks of the Docs to improve the readability and also scalability: 1) In the -help text: Delete the extra specific declaration and describe each topology parameter level by level. Then add a note to declare that different machines may support different subsets and the actual meaning of the supported parameters will vary accordingly. 2) In the rST text: List all the sub-hierarchies currently supported in QEMU, and correspondingly give an example of -smp configuration for each of them. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211228092221.21068-2-wangyanan55@huawei.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-12-21audio: add "dbus" audio backendMarc-André Lureau1-0/+3
Add a new -audio backend that accepts D-Bus clients/listeners to handle playback & recording, to be exported via the -display dbus. Example usage: -audiodev dbus,in.mixing-engine=off,out.mixing-engine=off,id=dbus -display dbus,audiodev=dbus Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2021-12-21ui/dbus: add p2p=on/off optionMarc-André Lureau1-2/+4
Add an option to use direct connections instead of via the bus. Clients are accepted with QMP add_client. This allows to provide the D-Bus display without a bus. It also simplifies the testing setup (some CI have issues to setup a D-Bus bus in a container). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2021-12-21ui: add a D-Bus display backendMarc-André Lureau1-0/+15
The "dbus" display backend exports the QEMU consoles and other UI-related interfaces over D-Bus. By default, the connection is established on the session bus, but you can specify a different bus with the "addr" option. The backend takes the "org.qemu" service name, while still allowing further instances to queue on the same name (so you can lookup all the available instances too). It accepts any number of clients at this point, although this is expected to evolve with options to restrict clients, or only accept p2p via fd passing. The interface is intentionally very close to the internal QEMU API, and can be introspected or interacted with busctl/dfeet etc: $ ./qemu-system-x86_64 -name MyVM -display dbus $ busctl --user introspect org.qemu /org/qemu/Display1/Console_0 org.qemu.Display1.Console interface - - - .RegisterListener method h - - .SetUIInfo method qqiiuu - - .DeviceAddress property s "pci/0000/01.0" emits-change .Head property u 0 emits-change .Height property u 480 emits-change .Label property s "VGA" emits-change .Type property s "Graphic" emits-change .Width property u 640 emits-change [...] See the interfaces XML source file and Sphinx docs for the generated API documentations. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2021-12-10numa: Enable numa for SGX EPC sectionsYang Zhong1-2/+2
The basic SGX did not enable numa for SGX EPC sections, which result in all EPC sections located in numa node 0. This patch enable SGX numa function in the guest and the EPC section can work with RAM as one numa node. The Guest kernel related log: [ 0.009981] ACPI: SRAT: Node 0 PXM 0 [mem 0x180000000-0x183ffffff] [ 0.009982] ACPI: SRAT: Node 1 PXM 1 [mem 0x184000000-0x185bfffff] The SRAT table can normally show SGX EPC sections menory info in different numa nodes. The SGX EPC numa related command: ...... -m 4G,maxmem=20G \ -smp sockets=2,cores=2 \ -cpu host,+sgx-provisionkey \ -object memory-backend-ram,size=2G,host-nodes=0,policy=bind,id=node0 \ -object memory-backend-epc,id=mem0,size=64M,prealloc=on,host-nodes=0,policy=bind \ -numa node,nodeid=0,cpus=0-1,memdev=node0 \ -object memory-backend-ram,size=2G,host-nodes=1,policy=bind,id=node1 \ -object memory-backend-epc,id=mem1,size=28M,prealloc=on,host-nodes=1,policy=bind \ -numa node,nodeid=1,cpus=2-3,memdev=node1 \ -M sgx-epc.0.memdev=mem0,sgx-epc.0.node=0,sgx-epc.1.memdev=mem1,sgx-epc.1.node=1 \ ...... Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20211101162009.62161-2-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-18qapi/qom,target/i386: sev-guest: Introduce kernel-hashes=on|off optionDov Murik1-1/+5
Introduce new boolean 'kernel-hashes' option on the sev-guest object. It will be used to to decide whether to add the hashes of kernel/initrd/cmdline to SEV guest memory when booting with -kernel. The default value is 'off'. Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Acked-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-08docs: remove non-reference uses of single backticksJohn Snow1-2/+2
The single backtick markup in ReST is the "default role". Currently, Sphinx's default role is called "content". Sphinx suggests you can use the "Any" role instead to turn any single-backtick enclosed item into a cross-reference. This is useful for things like autodoc for Python docstrings, where it's often nicer to reference other types with `foo` instead of the more laborious :py:meth:`foo`. It's also useful in multi-domain cases to easily reference definitions from other Sphinx domains, such as referencing C code definitions from outside of kerneldoc comments. Before we do that, though, we'll need to turn all existing usages of the "content" role to inline verbatim markup wherever it does not correctly resolve into a cross-refernece by using double backticks instead. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20211004215238.1523082-2-jsnow@redhat.com>
2021-10-29qapi: Extend -compat to set policy for unstable interfacesMarkus Armbruster1-1/+19
New option parameters unstable-input and unstable-output set policy for unstable interfaces just like deprecated-input and deprecated-output set policy for deprecated interfaces (see commit 6dd75472d5 "qemu-options: New -compat to set policy for deprecated interfaces"). This is intended for testing users of the management interfaces. It is experimental. For now, this covers only syntactic aspects of QMP, i.e. stuff tagged with feature 'unstable'. We may want to extend it to cover semantic aspects, or the command line. Note that there is no good way for management application to detect presence of these new option parameters: they are not visible output of query-qmp-schema or query-command-line-options. Tolerable, because it's meant for testing. If running with -compat fails, skip the test. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: John Snow <jsnow@redhat.com> Message-Id: <20211028102520.747396-10-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> [Doc comments fixed up]
2021-10-04qemu-options: Add missing "sockets=2, maxcpus=2" to CLI "-smp 2"Yanan Wang1-1/+1
There is one numa config example in qemu-options.hx currently using "-smp 2" and assuming that there will be 2 sockets and 2 cpus totally. However now the actual calculation logic of missing sockets and cores is not immutable and is considered liable to change. Although we will get maxcpus=2 finally based on current parser, it's always stable to specify it explicitly. So "-smp 2,sockets=2,maxcpus=2" will be optimal when we expect multiple sockets and 2 cpus totally. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-Id: <20210928121134.21064-3-wangyanan55@huawei.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-04qemu-options: Tweak [, maxcpus=cpus] to [, maxcpus=maxcpus]Yanan Wang1-1/+1
In qemu-option.hx, there is "-smp [[cpus=]n][,maxcpus=cpus]..." in the DEF part, and "-smp [[cpus=]n][,maxcpus=maxcpus]..." in the RST part. Obviously the later is right, let's fix the previous one. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-Id: <20210928121134.21064-2-wangyanan55@huawei.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-04qemu-options: -chardev reconnect=seconds duplicated in help, tidy upMarkus Armbruster1-1/+1
Fixes: 5dd1f02b4bc2f2c2ef3a2adfd8a412c8c8769085 Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210928071449.1416022-1-armbru@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-01machine: Prefer cores over sockets in smp parsing since 6.2Yanan Wang1-1/+2
In the real SMP hardware topology world, it's much more likely that we have high cores-per-socket counts and few sockets totally. While the current preference of sockets over cores in smp parsing results in a virtual cpu topology with low cores-per-sockets counts and a large number of sockets, which is just contrary to the real world. Given that it is better to make the virtual cpu topology be more reflective of the real world and also for the sake of compatibility, we start to prefer cores over sockets over threads in smp parsing since machine type 6.2 for different arches. In this patch, a boolean "smp_prefer_sockets" is added, and we only enable the old preference on older machines and enable the new one since type 6.2 for all arches by using the machine compat mechanism. Suggested-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-10-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-01machine: Set the value of cpus to match maxcpus if it's omittedYanan Wang1-3/+8
Currently we directly calculate the omitted cpus based on the given incomplete collection of parameters. This makes some cmdlines like: -smp maxcpus=16 -smp sockets=2,maxcpus=16 -smp sockets=2,dies=2,maxcpus=16 -smp sockets=2,cores=4,maxcpus=16 not work. We should probably set the value of cpus to match maxcpus if it's omitted, which will make above configs start to work. So the calculation logic of cpus/maxcpus after this patch will be: When both maxcpus and cpus are omitted, maxcpus will be calculated from the given parameters and cpus will be set equal to maxcpus. When only one of maxcpus and cpus is given then the omitted one will be set to its counterpart's value. Both maxcpus and cpus may be specified, but maxcpus must be equal to or greater than cpus. Note: change in this patch won't affect any existing working cmdlines but allows more incomplete configs to be valid. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-6-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-01machine: Deprecate "parameter=0" SMP configurationsYanan Wang1-5/+7
In the SMP configuration, we should either provide a topology parameter with a reasonable value (greater than zero) or just omit it and QEMU will compute the missing value. The users shouldn't provide a configuration with any parameter of it specified as zero (e.g. -smp 8,sockets=0) which could possibly cause unexpected results in the -smp parsing. So we deprecate this kind of configurations since 6.2 by adding the explicit sanity check. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-3-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30vl: Add sgx compound properties to expose SGX EPC sections to guestSean Christopherson1-2/+8
Because SGX EPC is enumerated through CPUID, EPC "devices" need to be realized prior to realizing the vCPUs themselves, i.e. long before generic devices are parsed and realized. From a virtualization perspective, the CPUID aspect also means that EPC sections cannot be hotplugged without paravirtualizing the guest kernel (hardware does not support hotplugging as EPC sections must be locked down during pre-boot to provide EPC's security properties). So even though EPC sections could be realized through the generic -devices command, they need to be created much earlier for them to actually be usable by the guest. Place all EPC sections in a contiguous block, somewhat arbitrarily starting after RAM above 4g. Ensuring EPC is in a contiguous region simplifies calculations, e.g. device memory base, PCI hole, etc..., allows dynamic calculation of the total EPC size, e.g. exposing EPC to guests does not require -maxmem, and last but not least allows all of EPC to be enumerated in a single ACPI entry, which is expected by some kernels, e.g. Windows 7 and 8. The new compound properties command for sgx like below: ...... -object memory-backend-epc,id=mem1,size=28M,prealloc=on \ -object memory-backend-epc,id=mem2,size=10M \ -M sgx-epc.0.memdev=mem1,sgx-epc.1.memdev=mem2 Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-6-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-06softmmu/vl: Deprecate the old grab optionsThomas Huth1-4/+8
The alt_grab and ctrl_grab parameter of the -display sdl option prevent the QAPIfication of the "sdl" part of the -display option, so we should eventually remove them. And since this feature is also rather niche anyway, we should not clutter the top-level option list with these, so let's also deprecate the "-alt-grab" and the "-ctrl-grab" options while we're at it. Once the deprecation period of "alt_grab" and "ctrl_grab" is over, we then can finally switch the -display sdl option to use QAPI internally, too. Message-Id: <20210825092023.81396-3-thuth@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06softmmu/vl: Add a "grab-mod" parameter to the -display sdl optionThomas Huth1-1/+5
The -display sdl option is not using QAPI internally yet, and uses hand- crafted parsing instead (see parse_display() in vl.c), which is quite ugly, since most of the other code is using the QAPIfied DisplayOption already. Unfortunately, the "alt_grab" and "ctrl_grab" use underscores in their names which has recently been forbidden in new QAPI code, so a straight conversion is not possible. While we could add some exceptions to the QAPI schema parser for this, the way these parameters have been designed was maybe a bad idea anyway: First, it's not possible to enable both parameters at the same time, thus instead of two boolean parameters it would be better to have only one multi-choice parameter instead. Second, the naming is also somewhat unfortunate since the "alt_grab" parameter is not about the ALT key, but rather about the left SHIFT key that has to be used additionally when the parameter is enabled. So instead of trying to QAPIfy "alt_grab" and "ctrl_grab", let's rather introduce an alternative to these parameters instead, a new parameter called "grab-mod" which can either be set to "lshift-lctrl-lalt" or to "rctrl". In case we ever want to support additional modes later, we can then also simply extend the list of supported strings here. Message-Id: <20210825092023.81396-2-thuth@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-02plugins: allow plugin arguments to be passed directlyMahmoud Mandour1-5/+4
Passing arguments to plugins had to be done through "arg=<argname>". This is redundant and introduces confusion especially when the argument has a name and value (e.g. `-plugin plugin_name,arg="argname=argvalue"`). This allows passing plugin arguments directly e.g: `-plugin plugin_name,argname=argvalue` For now, passing arguments through "arg=" is still supports but outputs a deprecation warning. Also, this commit makes boolean arguments passed to plugins in the `argname=on|off` form instead of the deprecated short-boolean form. Signed-off-by: Mahmoud Mandour <ma.mandourr@gmail.com> Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210730135817.17816-2-ma.mandourr@gmail.com>
2021-07-27qemu-options.hx: Fix formatting of -machine memory-backend optionPeter Maydell1-13/+17
The documentation of the -machine memory-backend has some minor formatting errors: * Misindentation of the initial line meant that the whole option section is incorrectly indented in the HTML output compared to the other -machine options * The examples weren't indented, which meant that they were formatted as plain run-on text including outputting the "::" as text. * The a) b) list has no rst-format markup so it is rendered as a single run-on paragraph Fix the formatting. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20210719105257.3599-1-peter.maydell@linaro.org
2021-07-21iothread: add aio-max-batch parameterStefano Garzarella1-2/+6
The `aio-max-batch` parameter will be propagated to AIO engines and it will be used to control the maximum number of queued requests. When there are in queue a number of requests equal to `aio-max-batch`, the engine invokes the system call to forward the requests to the kernel. This parameter allows us to control the maximum batch size to reduce the latency that requests might accumulate while queued in the AIO engine queue. If `aio-max-batch` is equal to 0 (default value), the AIO engine will use its default maximum batch size value. Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Message-id: 20210721094211.69853-3-sgarzare@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-07-16docs: Add '-device intel-iommu' entryPeter Xu1-0/+33
The parameters of intel-iommu device are non-trivial to understand. Add an entry for it so that people can reference to it when using. There're actually a few more options there, but I hide them explicitly because they shouldn't be used by normal QEMU users. Cc: Chao Yang <chayang@redhat.com> Cc: Lei Yang <leiyang@redhat.com> Cc: Jing Zhao <jinzhao@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20210707154114.197580-1-peterx@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-07-14qemu-options: rewrite help for -smp optionsDaniel P. Berrangé1-8/+21
The -smp option help is peculiarly specific about mentioning the CPU upper limits, but these are wrong. The "PC" target has varying max CPU counts depending on the machine type picked. Notes about guest OS limits are inappropriate for QEMU docs. There are way too many machine types for it to be practical to mention actual limits, and some limits are even modified by downstream distribtions. Thus it is better to remove the specific limits entirely. The CPU topology reporting is also not neccessarily specific to the PC platform and descriptions around the rules of usage are somewhat terse. Expand this information with some examples to show effects of defaulting. Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-07-14qemu-options: tweak to show that CPU count is optionalDaniel P. Berrangé1-2/+2
The initial CPU count number is not required, if any of the topology options are given, since it can be computed. Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Yanan Wang <wangyanan55@huawei.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-07-14qemu-options: re-arrange CPU topology optionsDaniel P. Berrangé1-6/+6
The list of CPU topology options are presented in a fairly arbitrary order currently. Re-arrange them so that they're ordered from largest to smallest unit Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Yanan Wang <wangyanan55@huawei.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-07-05qemu-options: Improve the documentation of the -display optionsThomas Huth1-12/+33
The sdl and gtk display options support more parameters than currently documented. Also the "vnc" option got lost during a recent commit, add it again. Fixes: ddc717581c ("Add display suboptions to man pages") Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210630163231.467987-5-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-07-05ui: Mark the '-no-quit' option as deprecatedThomas Huth1-2/+3
It's just a wrapper around the -display ...,window-close=off parameter, and the name "no-quit" is rather confusing compared to "window-close" (since there are still other means to quit the emulator), so we should rather tell our users to use the "window-close" parameter instead. While we're at it, update the documentation to state that "-no-quit" is available for GTK, too, not only for SDL. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210630163231.467987-4-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-07-05ui: Fix the "-display sdl,window_close=..." parameterThomas Huth1-1/+1
According to the QAPI schema, there is a "-" and not a "_" between "window" and "close", and we're also talking about "window-close" in the long parameter description in qemu-options.hx, so we should make sure that we rather use the variant with the "-" by default instead of only allowing the one with the "_" here. The old way still stays enabled for compatibility, but we deprecate it, so that we can switch to a QAPIfied parameter one day more easily. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210630163231.467987-3-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-06-23Add display suboptions to man pagesAhmed Abouzied1-17/+18
Updates man pages with the suboptions for the `-display`. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/128 Buglink: https://bugs.launchpad.net/qemu/+bug/1620660 Signed-off-by: Ahmed Abouzied <email@aabouzied.com> Message-Id: <20210601174117.661-1-email@aabouzied.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-05-26doc: Add notes about -mon option mode=control argument.Ali Shirvani1-2/+5
The mode=control argument configures a QMP monitor. Signed-off-by: Ali Shirvani <alishir@routerhosting.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <0799f0de89ad2482672b5d61d0de61e6eba782da.1621407918.git.alishir@routerhosting.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-26remove qemu-options* from root directoryPaolo Bonzini1-0/+4
These headers are also included from softmmu/vl.c, so they should be in include/. Remove qemu-options-wrapper.h, since elsewhere we include "template" headers directly and #define the parameters in the including file; move qemu-options.h to include/. Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-26KVM: Add dirty-ring-size propertyPeter Xu1-0/+12
Add a parameter for dirty gfn count for dirty rings. If zero, dirty ring is disabled. Otherwise dirty ring will be enabled with the per-vcpu gfn count as specified. If dirty ring cannot be enabled due to unsupported kernel or illegal parameter, it'll fallback to dirty logging. By default, dirty ring is not enabled (dirty-gfn-count default to 0). Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20210506160549.130416-9-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-16Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell1-1/+29
pc,pci,virtio: bugfixes, improvements Fixes all over the place. Faster boot for virtio. ioeventfd support for mmio. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Fri 14 May 2021 15:27:13 BST # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: Fix build with 64 bits time_t vhost-vdpa: Make vhost_vdpa_get_device_id() static hw/virtio: enable ioeventfd configuring for mmio hw/smbios: support for type 41 (onboard devices extended information) checkpatch: Fix use of uninitialized value virtio-scsi: Configure all host notifiers in a single MR transaction virtio-scsi: Set host notifiers and callbacks separately virtio-blk: Configure all host notifiers in a single MR transaction virtio-blk: Fix rollback path in virtio_blk_data_plane_start() pc-dimm: remove unnecessary get_vmstate_memory_region() method amd_iommu: fix wrong MMIO operations virtio-net: Constify VirtIOFeature feature_sizes[] virtio-blk: Constify VirtIOFeature feature_sizes[] hw/virtio: Pass virtio_feature_get_config_size() a const argument x86: acpi: use offset instead of pointer when using build_header() amd_iommu: Fix pte_override_page_mask() Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # hw/arm/virt.c
2021-05-14hw/smbios: support for type 41 (onboard devices extended information)Vincent Bernat1-1/+29
Type 41 defines the attributes of devices that are onboard. The original intent was to imply the BIOS had some level of control over the enablement of the associated devices. If network devices are present in this table, by default, udev will name the corresponding interfaces enoX, X being the instance number. Without such information, udev will fallback to using the PCI ID and this usually gives ens3 or ens4. This can be a bit annoying as the name of the network card may depend on the order of options and may change if a new PCI device is added earlier on the commande line. Being able to provide SMBIOS type 41 entry ensure the name of the interface won't change and helps the user guess the right name without booting a first time. This can be invoked with: $QEMU -netdev user,id=internet -device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \ -smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev The PCI segment is assumed to be 0. This should hold true for most cases. $ dmidecode -t 41 # dmidecode 3.3 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. Handle 0x2900, DMI type 41, 11 bytes Onboard Device Reference Designation: Onboard LAN Type: Ethernet Status: Enabled Type Instance: 1 Bus Address: 0000:00:09.0 $ ip -brief a lo UNKNOWN 127.0.0.1/8 ::1/128 eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64 Signed-off-by: Vincent Bernat <vincent@bernat.ch> Message-Id: <20210401171138.62970-1-vincent@bernat.ch> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-05-12Drop the deprecated lm32 targetMarkus Armbruster1-2/+2
Target lm32 was deprecated in commit d8498005122, v5.2.0. See there for rationale. Some of its code lives on in device models derived from milkymist ones: hw/char/digic-uart.c and hw/display/bcm2835_fb.c. Cc: Michael Walle <michael@walle.cc> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210503084034.3804963-2-armbru@redhat.com> Acked-by: Michael Walle <michael@walle.cc> [Trivial conflicts resolved, reST markup fixed]
2021-05-06Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into ↵Peter Maydell1-4/+4
staging * NetBSD NVMM support * RateLimit mutex * Prepare for Meson 0.57 upgrade # gpg: Signature made Tue 04 May 2021 13:15:37 BST # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini-gitlab/tags/for-upstream: glib-compat: accept G_TEST_SLOW environment variable gitlab-ci: use --meson=internal for CFI jobs configure: handle meson options that have changed type configure: reindent meson invocation slirp: add configure option to disable smbd ratelimit: protect with a mutex Add NVMM Accelerator: add maintainers for NetBSD/NVMM Add NVMM accelerator: acceleration enlightenments Add NVMM accelerator: x86 CPU support Add NVMM accelerator: configure and build logic oslib-win32: do not rely on macro to get redefined function name Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-05-04Add NVMM accelerator: configure and build logicReinoud Zandijk1-4/+4
Signed-off-by: Kamil Rytarowski <kamil@NetBSD.org> Signed-off-by: Reinoud Zandijk <reinoud@NetBSD.org> Message-Id: <20210402202535.11550-2-reinoud@NetBSD.org> [Check for nvmm_vcpu_stop. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-03docs: More precisely describe memory-backend-*::id's userRobert Hoo1-3/+3
'id' of memory-backend-{file,ram} is not only for '-numa''s reference, but also other parameters like '-device nvdimm'. More clearly call out this to avoid misinterpretation. Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1619080922-83527-1-git-send-email-robert.hu@linux.intel.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-03-26usb: Remove "-usbdevice ccid"Thomas Huth1-3/+0
"-usbdevice ccid" was not documented and -usbdevice itself was marked as deprecated before QEMU v6.0. And searching for "-usbdevice ccid" in the internet does not show any useful results, so likely nobody was using the ccid device via the -usbdevice option. Remove it now. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210311092829.1479051-1-thuth@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-03-19qapi: New -compat deprecated-input=crashMarkus Armbruster1-1/+3
Policy "crash" calls abort() when deprecated input is received. Bugs in integration tests may mask the error from policy "reject". Provide a larger hammer: crash outright. Masking that seems unlikely. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20210318155519.1224118-12-armbru@redhat.com>
2021-03-19qemu-options: New -compat to set policy for deprecated interfacesMarkus Armbruster1-0/+20
New option -compat lets you configure what to do when deprecated interfaces get used. This is intended for testing users of the management interfaces. It is experimental. -compat deprecated-input=<input-policy> configures what to do when deprecated input is received. Input policy can be "accept" (accept silently), or "reject" (reject the request with an error). -compat deprecated-output=<out-policy> configures what to do when deprecated output is sent. Output policy can be "accept" (pass on unchanged), or "hide" (filter out the deprecated parts). Default is "accept". Policies other than "accept" are implemented later in this series. For now, -compat covers only syntactic aspects of QMP, i.e. stuff tagged with feature 'deprecated'. We may want to extend it to cover semantic aspects, CLI, and experimental features. Note that there is no good way for management application to detect presence of -compat: it's not visible output of query-qmp-schema or query-command-line-options. Tolerable, because it's meant for testing. If running with -compat fails, skip the test. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20210318155519.1224118-3-armbru@redhat.com>
2021-03-18monitor: raise error when 'pretty' option is used with HMPDaniel P. Berrangé1-2/+3
This is only semantically useful for QMP. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
generated by cgit v1.1 at 2024-12-28 19:00:48 +0000