aboutsummaryrefslogtreecommitdiff
path: root/qemu-options.hx
AgeCommit message (Collapse)AuthorFilesLines
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>
2021-03-17Merge remote-tracking branch 'remotes/kraxel/tags/ui-20210316-pull-request' ↵Peter Maydell1-2/+16
into staging vnc+spice: password-secret option. bugfixes for cocoa, vnc, opengl. # gpg: Signature made Tue 16 Mar 2021 05:37:58 GMT # gpg: using RSA key A0328CFFB93A17A79901FE7D4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/ui-20210316-pull-request: ui/cocoa: Comment about modifier key input quirks ui: fold qemu_alloc_display in only caller ui: honour the actual guest display dimensions without rounding ui: use client width/height in WMVi message ui: avoid sending framebuffer updates outside client desktop bounds ui: add more trace points for VNC client/server messages ui/cocoa: Do not exit immediately after shutdown opengl: Do not convert format with glTexImage2D on OpenGL ES ui: deprecate "password" option for SPICE server ui: introduce "password-secret" option for SPICE server ui: introduce "password-secret" option for VNC servers Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-03-15ui: deprecate "password" option for SPICE serverDaniel P. Berrangé1-0/+4
With the new "password-secret" option, there is no reason to use the old inecure "password" option with -spice, so it can be deprecated. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210311114343.439820-4-berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-03-15ui: introduce "password-secret" option for SPICE serverDaniel P. Berrangé1-2/+7
Currently when using SPICE the "password" option provides the password in plain text on the command line. This is insecure as it is visible to all processes on the host. As an alternative, the password can be provided separately via the monitor. This introduces a "password-secret" option which lets the password be provided up front. $QEMU --object secret,id=vncsec0,file=passwd.txt \ --spice port=5901,password-secret=vncsec0 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210311114343.439820-3-berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-03-15ui: introduce "password-secret" option for VNC serversDaniel P. Berrangé1-0/+5
Currently when using VNC the "password" flag turns on password based authentication. The actual password has to be provided separately via the monitor. This introduces a "password-secret" option which lets the password be provided up front. $QEMU --object secret,id=vncsec0,file=passwd.txt \ --vnc localhost:0,password-secret=vncsec0 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210311114343.439820-2-berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-03-15usb: Document the missing -usbdevice optionsThomas Huth1-6/+29
There are some more -usbdevice options that have never been mentioned in the documentation. Now that we removed -usbdevice from the list of deprecated features again, we should document them properly. While we're at it, also sort them alphabetically. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210310173323.1422754-5-thuth@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-03-09qemu-options: Replace the word 'blacklist'Philippe Mathieu-Daudé1-3/+3
Follow the inclusive terminology from the "Conscious Language in your Open Source Projects" guidelines [*] and replace the word "blacklist" appropriately. [*] https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210303184644.1639691-5-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-03-09Various spelling fixesMichael Tokarev1-2/+2
An assorted set of spelling fixes in various places. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210309111510.79495-1-mjt@msgid.tls.msk.ru> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-03-06chardev: add nodelay optionPaolo Bonzini1-7/+7
The "delay" option was introduced as a way to enable Nagle's algorithm with ",nodelay". Since the short form for boolean options has now been deprecated, introduce a more properly named "nodelay" option. The "delay" option remains as an undocumented option. "delay" and "nodelay" are mutually exclusive. Because the check is done at consumption time, the code also rejects them if one of the two is specified via -set. Based-on: <20210226080526.651705-1-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-25vl: deprecate -writeconfigPaolo Bonzini1-6/+1
The functionality of -writeconfig is limited and the code 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) so remove it. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-25qemu-options: update to show preferred boolean syntax for -vncDaniel P. Berrangé1-8/+8
The preferred syntax is to use "foo=on|off", rather than a bare "foo" or "nofoo". The on|off syntax has been supported since -vnc switched to use QemuOpts in commit 4db14629c38611061fc19ec6927405923de84f08 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210216191027.595031-7-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-25qemu-options: update to show preferred boolean syntax for -incomingDaniel P. Berrangé1-4/+4
The preferred syntax is to use "foo=on|off", rather than a bare "foo" or "nofoo". Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210216191027.595031-6-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-25qemu-options: update to show preferred boolean syntax for -netdevDaniel P. Berrangé1-5/+5
The preferred syntax is to use "foo=on|off", rather than a bare "foo" or "nofoo". Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210216191027.595031-5-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-25qemu-options: update to show preferred boolean syntax for -spiceDaniel P. Berrangé1-9/+10
The preferred syntax is to use "foo=on|off", rather than a bare "foo" or "nofoo". Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210216191027.595031-4-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-25qemu-options: update to show preferred boolean syntax for -chardevDaniel P. Berrangé1-39/+39
The preferred syntax is to use "foo=on|off", rather than a bare "foo" or "nofoo". Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210216191027.595031-3-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-08machine: add missing doc for memory-backend optionIgor Mammedov1-1/+25
Add documentation for '-machine memory-backend' CLI option and how to use it. And document that x-use-canonical-path-for-ramblock-id, is considered to be stable to make sure it won't go away by accident. x- was intended for unstable/iternal properties, and not supposed to be stable option. However it's too late to rename (drop x-) it as it would mean that users will have to mantain both x-use-canonical-path-for-ramblock-id (for QEMU 5.0-5.2) versions and prefix-less for later versions. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20210121161504.1007247-1-imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-01hostmem-file: add readonly=on|off optionStefan Hajnoczi1-1/+4
Let -object memory-backend-file work on read-only files when the readonly=on option is given. This can be used to share the contents of a file between multiple guests while preventing them from consuming Copy-on-Write memory if guests dirty the pages, for example. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20210104171320.575838-3-stefanha@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-01-29Prefer 'on' | 'off' over 'yes' | 'no' for bool optionsDaniel P. Berrangé1-2/+2
Update some docs and test cases to use 'on' | 'off' as the preferred value for bool options. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
generated by cgit v1.1 at 2024-11-02 21:17:50 +0000