aboutsummaryrefslogtreecommitdiff
path: root/qemu-options.hx
AgeCommit message (Collapse)Author
2022-09-19audio: add help option for -audio and -audiodevClaudio Fontana
add a simple help option for -audio and -audiodev to show the list of available drivers, and document them. Signed-off-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20220908081441.7111-1-cfontana@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-13semihosting: Allow optional use of semihosting from userspacePeter Maydell
Currently our semihosting implementations generally prohibit use of semihosting calls in system emulation from the guest userspace. This is a very long standing behaviour justified originally "to provide some semblance of security" (since code with access to the semihosting ABI can do things like read and write arbitrary files on the host system). However, it is sometimes useful to be able to run trusted guest code which performs semihosting calls from guest userspace, notably for test code. Add a command line suboption to the existing semihosting-config option group so that you can explicitly opt in to semihosting from guest userspace with -semihosting-config userspace=on (There is no equivalent option for the user-mode emulator, because there by definition all code runs in userspace and has access to semihosting already.) This commit adds the infrastructure for the command line option and adds a bool 'is_user' parameter to the function semihosting_userspace_enabled() that target code can use to check whether it should be permitting the semihosting call for userspace. It mechanically makes all the callsites pass 'false', so they continue checking "is semihosting enabled in general". Subsequent commits will make each target that implements semihosting honour the userspace=on option by passing the correct value and removing whatever "don't do this for userspace" checking they were doing by hand. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220822141230.3658237-2-peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-08-24qemu-options: try and clarify preferred block semanticsAlex Bennée
Try to correct any confusion about QEMU's Byzantine disk options by laying out the preferred "modern" options as-per: "<danpb> (best: -device + -blockdev, 2nd obsolete syntax: -device + -drive, 3rd obsolete syntax: -drive, 4th obsolete syntax: -hdNN)" Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Cc: qemu-block@nongnu.org Cc: Kevin Wolf <kwolf@redhat.com> Cc: Hanna Reitz <hreitz@redhat.com> Cc: Thomas Huth <thuth@redhat.com> Message-Id: <20220822165608.2980552-7-alex.bennee@linaro.org>
2022-07-29qemu-options: bring the kernel and image options togetherAlex Bennée
How to control the booting of QEMU is often a source of confusion for users. Bring the options that control this together in the manual pages and add some verbiage to describe when each option is appropriate. This attempts to codify some of the knowledge expressed in: https://stackoverflow.com/questions/58420670/qemu-bios-vs-kernel-vs-device-loader-file/58434837#58434837 Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220725140520.515340-14-alex.bennee@linaro.org>
2022-07-29qapi: Add exit-failure PanicActionIlya Leoshkevich
Currently QEMU exits with code 0 on both panic an shutdown. For tests it is useful to return 1 on panic, so that it counts as a test failure. Introduce a new exit-failure PanicAction that makes main() return EXIT_FAILURE. Tests can use -action panic=exit-failure option to activate this behavior. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20220725223746.227063-2-iii@linux.ibm.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2022-07-19gtk: Add show_tabs=on|off command line option.Felix xq Queißner
The patch adds "show_tabs" command line option for GTK ui similar to "grab_on_hover". This option allows tabbed view mode to not have to be enabled by hand at each start of the VM. Signed-off-by: Felix "xq" Queißner <xq@random-projects.net> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Message-Id: <20220712133753.18937-1-xq@random-projects.net> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2022-06-09hw/cxl: Make the CXL fixed memory window setup a machine parameter.Jonathan Cameron
Paolo Bonzini requested this change to simplify the ongoing effort to allow machine setup entirely via RPC. Includes shortening the command line form cxl-fixed-memory-window to cxl-fmw as the command lines are extremely long even with this change. The json change is needed to ensure that there is a CXLFixedMemoryWindowOptionsList even though the actual element in the json is never used. Similar to existing SgxEpcProperties. Update qemu-options.hx to reflect that this is now a -machine parameter. The bulk of -M / -machine parameters are documented under machine, so use that in preference to M. Update cxl-test and bios-tables-test to reflect new parameters. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Davidlohr Bueso <dave@stgolabs.net> Message-Id: <20220608145440.26106-2-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-03ui: Remove deprecated options "-sdl" and "-curses"Thomas Huth
We have "-sdl" and "-curses", but no "-gtk" and no "-cocoa" ... these old-style options are rather confusing than helpful nowadays. Now that the deprecation period is over, let's remove them, so we get a cleaner interface (where "-display" is the only way to select the user interface). Message-Id: <20220519155625.1414365-4-thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-06-03ui: Remove deprecated parameters of the "-display sdl" optionThomas Huth
Dropping these deprecated parameters simplifies further refactoring (e.g. QAPIfication is easier without underscores in the name). Message-Id: <20220519155625.1414365-2-thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-05-17net/vmnet: update qemu-options.hxVladislav Yaroshchuk
Update qemu-options.hx to support vmnet networking backend. Reviewed-by: Akihiko Odaki <akihiko.odaki@gmail.com> Tested-by: Akihiko Odaki <akihiko.odaki@gmail.com> Signed-off-by: Vladislav Yaroshchuk <Vladislav.Yaroshchuk@jetbrains.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-05-16Merge tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Richard Henderson
into staging virtio,pc,pci: fixes,cleanups,features most of CXL support fixes, cleanups all over the place Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmKCuLIPHG1zdEByZWRo # YXQuY29tAAoJECgfDbjSjVRpdDUH/12SmWaAo+0+SdIHgWFFxsmg3t/EdcO38fgi # MV+GpYdbp6TlU3jdQhrMZYmFdkVVydBdxk93ujCLbFS0ixTsKj31j0IbZMfdcGgv # SLqnV+E3JdHqnGP39q9a9rdwYWyqhkgHoldxilIFW76ngOSapaZVvnwnOMAMkf77 # 1LieL4/Xq7N9Ho86Zrs3IczQcf0czdJRDaFaSIu8GaHl8ELyuPhlSm6CSqqrEEWR # PA/COQsLDbLOMxbfCi5v88r5aaxmGNZcGbXQbiH9qVHw65nlHyLH9UkNTdJn1du1 # f2GYwwa7eekfw/LCvvVwxO1znJrj02sfFai7aAtQYbXPvjvQiqA= # =xdSk # -----END PGP SIGNATURE----- # gpg: Signature made Mon 16 May 2022 01:48:50 PM PDT # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [undefined] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [undefined] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (86 commits) vhost-user-scsi: avoid unlink(NULL) with fd passing virtio-net: don't handle mq request in userspace handler for vhost-vdpa vhost-vdpa: change name and polarity for vhost_vdpa_one_time_request() vhost-vdpa: backend feature should set only once vhost-net: fix improper cleanup in vhost_net_start vhost-vdpa: fix improper cleanup in net_init_vhost_vdpa virtio-net: align ctrl_vq index for non-mq guest for vhost_vdpa virtio-net: setup vhost_dev and notifiers for cvq only when feature is negotiated hw/i386/amd_iommu: Fix IOMMU event log encoding errors hw/i386: Make pic a property of common x86 base machine type hw/i386: Make pit a property of common x86 base machine type include/hw/pci/pcie_host: Correct PCIE_MMCFG_SIZE_MAX include/hw/pci/pcie_host: Correct PCIE_MMCFG_BUS_MASK docs/vhost-user: Clarifications for VHOST_USER_ADD/REM_MEM_REG vhost-user: more master/slave things virtio: add vhost support for virtio devices virtio: drop name parameter for virtio_init() virtio/vhost-user: dynamically assign VhostUserHostNotifiers hw/virtio/vhost-user: don't suppress F_CONFIG when supported include/hw: start documenting the vhost API ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-05-14introduce -audio as a replacement for -soundhwPaolo Bonzini
-audio is used like "-audio pa,model=sb16". It is almost as simple as -soundhw, but it reuses the -audiodev parsing machinery and attaches an audiodev to the newly-created device. The main 'feature' is that it knows about adding the codec device for model=intel-hda, and adding the audiodev to the codec device. In the future, it could be extended to support default models or builtin devices, just like -nic, or even a default backend. For now, keep it simple. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-13hw/cxl/host: Add support for CXL Fixed Memory Windows.Jonathan Cameron
The concept of these is introduced in [1] in terms of the description the CEDT ACPI table. The principal is more general. Unlike once traffic hits the CXL root bridges, the host system memory address routing is implementation defined and effectively static once observable by standard / generic system software. Each CXL Fixed Memory Windows (CFMW) is a region of PA space which has fixed system dependent routing configured so that accesses can be routed to the CXL devices below a set of target root bridges. The accesses may be interleaved across multiple root bridges. For QEMU we could have fully specified these regions in terms of a base PA + size, but as the absolute address does not matter it is simpler to let individual platforms place the memory regions. ExampleS: -cxl-fixed-memory-window targets.0=cxl.0,size=128G -cxl-fixed-memory-window targets.0=cxl.1,size=128G -cxl-fixed-memory-window targets.0=cxl0,targets.1=cxl.1,size=256G,interleave-granularity=2k Specifies * 2x 128G regions not interleaved across root bridges, one for each of the root bridges with ids cxl.0 and cxl.1 * 256G region interleaved across root bridges with ids cxl.0 and cxl.1 with a 2k interleave granularity. When system software enumerates the devices below a given root bridge it can then decide which CFMW to use. If non interleave is desired (or possible) it can use the appropriate CFMW for the root bridge in question. If there are suitable devices to interleave across the two root bridges then it may use the 3rd CFMS. A number of other designs were considered but the following constraints made it hard to adapt existing QEMU approaches to this particular problem. 1) The size must be known before a specific architecture / board brings up it's PA memory map. We need to set up an appropriate region. 2) Using links to the host bridges provides a clean command line interface but these links cannot be established until command line devices have been added. Hence the two step process used here of first establishing the size, interleave-ways and granularity + caching the ids of the host bridges and then, once available finding the actual host bridges so they can be used later to support interleave decoding. [1] CXL 2.0 ECN: CEDT CFMWS & QTG DSM (computeexpresslink.org / specifications) Signed-off-by: Jonathan Cameron <jonathan.cameron@huawei.com> Acked-by: Markus Armbruster <armbru@redhat.com> # QAPI Schema Message-Id: <20220429144110.25167-28-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-05-09qemu-options: Limit the -xen options to x86 and armThomas Huth
The Xen hypervisor is only available on x86 and arm - thus let's limit the related options to these targets. Message-Id: <20220427133156.344418-1-thuth@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-04-28qemu-options: Limit the -enable-kvm option to the targets that support itThomas Huth
There is no need to present the user with -enable-kvm if there is no support for KVM on the corresponding target. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20220427134906.348118-1-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-28remove -writeconfigPaolo Bonzini
Like -set and -readconfig, it would not really be too hard to extend -writeconfig to parsing mechanisms other than QemuOpts. However, the uses of -writeconfig are substantially more limited, as it is generally easier to write the configuration by hand in the first place. In addition, -writeconfig does not even try to detect cases where it prints incorrect syntax (for example if values have a quote in them, since qemu_config_parse does not support any kind of escaping. Just remove it. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220414145721.326866-1-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-26softmmu: remove deprecated --enable-fips optionDaniel P. Berrangé
Users requiring FIPS support must build QEMU with either the libgcrypt or gnutls libraries as the crytography backend. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-03-22qemu-options: define -spice only #ifdef CONFIG_SPICEMarc-André Lureau
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 Silva
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 Silva
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 Ellis
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 Venture
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 Vivier
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 Wang
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 Huth
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 Wang
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 Wang
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é Lureau
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é Lureau
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é Lureau
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 Zhong
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 Murik
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 Snow
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 Armbruster
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 Wang
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 Wang
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 Armbruster
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 Wang
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 Wang
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 Wang
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 Christopherson
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 Huth
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 Huth
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 Mandour
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 Maydell
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 Garzarella
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 Xu
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é
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é
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é
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>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-11 17:59:49 +0000