summary refs log tree commit diff stats
path: root/scripts/qapi/expr.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2020-07-17tcg/cpu-exec: precise single-stepping after an interruptRichard Henderson1-1/+7
When single-stepping with a debugger attached to QEMU, and when an interrupt is raised, the debugger misses the first instruction after the interrupt. Tested-by: Luc Michel <luc.michel@greensocs.com> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Buglink: https://bugs.launchpad.net/qemu/+bug/757702 Message-Id: <20200717163029.2737546-1-richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-07-17ipmi: add SET_SENSOR_READING commandCédric Le Goater1-0/+223
SET_SENSOR_READING is a complex IPMI command (see IPMI spec 35.17) which enables the host software to set the reading value and the event status of sensors supporting it. Below is a proposal for all the operations (reading, assert, deassert, event data) with the following limitations : - No event are generated for threshold-based sensors. - The case in which the BMC needs to generate its own events is not supported. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Corey Minyard <cminyard@mvista.com> Message-Id: <20191118092429.16149-1-clg@kaod.org> [Moved the break statement for case SENSOR_GEN_EVENT_DATA above the closing brace to keep the indention consistent.] Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-17ipmi: Fix a man page entryCorey Minyard1-1/+1
The line was too long, and some of the entries were wrong (fur instead of fru). Just use the prop=val thing tha other entries use. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-17ipmi: Add man page pieces for the IPMI PCI devicesCorey Minyard1-0/+9
This was forgotten when the devices were added. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-17migration/block-dirty-bitmap: fix add_bitmaps_to_listVladimir Sementsov-Ogievskiy1-1/+5
We shouldn't fail when finding an unnamed bitmap in a unnamed node or node with auto-generated node name, as bitmap migration ignores such bitmaps in the first place. Fixes: 82640edb88faa Fixes: 4ff5cc121b089 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200626130658.76498-1-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> [eblake: commit message grammar tweaks] Signed-off-by: Eric Blake <eblake@redhat.com>
2020-07-17file-posix: Fix leaked fd in raw_open_common() error pathKevin Wolf1-0/+3
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200717105426.51134-4-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17file-posix: Fix check_hdev_writable() with auto-read-onlyKevin Wolf1-12/+21
For Linux block devices, being able to open the device read-write doesn't necessarily mean that the device is actually writable (one example is a read-only LV, as you get with lvchange -pr <device>). We have check_hdev_writable() to check this condition and fail opening the image read-write if it's not actually writable. However, this check doesn't take auto-read-only into account, but results in a hard failure instead of downgrading to read-only where possible. Fix this and do the writable check not based on BDRV_O_RDWR, but only when this actually results in opening the file read-write. A second check is inserted in raw_reconfigure_getfd() to have the same check when dynamic auto-read-only upgrades an image file from read-only to read-write. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200717105426.51134-3-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17file-posix: Move check_hdev_writable() upKevin Wolf1-33/+33
We'll need to call it in raw_open_common(), so move the function to avoid a forward declaration. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200717105426.51134-2-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17file-posix: Allow byte-aligned O_DIRECT with NFSKevin Wolf1-1/+25
Since commit a6b257a08e3 ('file-posix: Handle undetectable alignment'), we assume that if we open a file with O_DIRECT and alignment probing returns 1, we just couldn't find out the real alignment requirement because some filesystems make the requirement only for allocated blocks. In this case, a safe default of 4k is used. This is too strict for NFS, which does actually allow byte-aligned requests even with O_DIRECT. Because we can't distinguish both cases with generic code, let's just look at the file system magic and disable s->needs_alignment for NFS. This way, O_DIRECT can still be used on NFS for images that are not aligned to 4k. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200716142601.111237-3-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17block: Require aligned image size to avoid assertion failureKevin Wolf1-0/+16
Unaligned requests will automatically be aligned to bl.request_alignment and we can't extend write requests to access space beyond the end of the image without resizing the image, so if we have the WRITE permission, but not the RESIZE one, it's required that the image size is aligned. Failing to meet this requirement could cause assertion failures like this if RESIZE permissions weren't requested: qemu-img: block/io.c:1910: bdrv_co_write_req_prepare: Assertion `end_sector <= bs->total_sectors || child->perm & BLK_PERM_RESIZE' failed. This was e.g. triggered by qemu-img converting to a target image with 4k request alignment when the image was only aligned to 512 bytes, but not to 4k. Turn this into a graceful error in bdrv_check_perm() so that WRITE without RESIZE can only be taken if the image size is aligned. If a user holds both permissions and drops only RESIZE, the function will return an error, but bdrv_child_try_set_perm() will ignore the failure silently if permissions are only requested to be relaxed and just keep both permissions while returning success. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200716142601.111237-2-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17iotests: test shutdown when bitmap is exported through NBDVladimir Sementsov-Ogievskiy3-0/+76
Test shutdown when bitmap is exported through NBD and active client exists. The previous patch fixes a crash, provoked by this scenario. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Tested-by: Eric Blake <eblake@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200714162234.13113-3-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17nbd: make nbd_export_close_all() synchronousVladimir Sementsov-Ogievskiy1-0/+8
Consider nbd_export_close_all(). The call-stack looks like this: nbd_export_close_all() -> nbd_export_close -> call client_close() for each client. client_close() doesn't guarantee that client is closed: nbd_trip() keeps reference to it. So, nbd_export_close_all() just reduce reference counter on export and removes it from the list, but doesn't guarantee that nbd_trip() finished neither export actually removed. Let's wait for all exports actually removed. Without this fix, the following crash is possible: - export bitmap through internal Qemu NBD server - connect a client - shutdown Qemu On shutdown nbd_export_close_all is called, but it actually don't wait for nbd_trip() to finish and to release its references. So, export is not release, and exported bitmap remains busy, and on try to remove the bitmap (which is part of bdrv_close()) the assertion fails: bdrv_release_dirty_bitmap_locked: Assertion `!bdrv_dirty_bitmap_busy(bitmap)' failed Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200714162234.13113-2-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17iotests/030: Reduce job speed to make race less likelyKevin Wolf1-1/+1
It can happen that the throttling of the stream job doesn't make it slow enough that we can be sure that it still exists when it is referenced again. Just use a much smaller speed to make this very unlikely to happen again. Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200716132829.20127-1-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17crypto: use a stronger private key for testsDaniel P. Berrangé2-37/+79
The unit tests using the x509 crypto functionality have started failing in Fedora 33 rawhide with a message like The certificate uses an insecure algorithm This is result of Fedora changes to support strong crypto [1]. RSA with 1024 bit key is viewed as legacy and thus insecure. Generate a new private key which is 3072 bits long and reasonable future proof. [1] https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200715154701.1041325-1-berrange@redhat.com> Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17qemu-img resize: Require --shrink for shrinking all image formatsKevin Wolf1-11/+3
QEMU 2.11 introduced the --shrink option for qemu-img resize to avoid accidentally shrinking images (commit 4ffca8904a3). However, for compatibility reasons, it was not enforced for raw images yet, but only a deprecation warning was printed. This warning has existed for long enough that we can now finally require --shrink for raw images, too, and error out if it's not given. Documentation already describes the state as it is after this patch. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200710121717.28339-1-kwolf@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17Remove VXHS block deviceMarc-André Lureau18-718/+10
The vxhs code doesn't compile since v2.12.0. There's no point in fixing and then adding CI for a config that our users have demonstrated that they do not use; better to just remove it. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200711065926.2204721-1-marcandre.lureau@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17vvfat: set status to odd fixesPrasad J Pandit1-1/+1
Virtual VFAT driver is quite old and rarely used. Set its status to Odd Fixes. Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Message-Id: <20200710190451.761286-1-ppandit@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17docs/s390x: fix vfio-ccw typeCornelia Huck1-1/+1
Fix the type name in the mdevctl example. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20200716145031.771476-1-cohuck@redhat.com>
2020-07-17gitlab-ci.yml: Add fuzzer testsThomas Huth1-1/+19
So far we neither compile-tested nor run any of the new fuzzers in our CI, which led to some build failures of the fuzzer code in the past weeks. To avoid this problem, add a job to compile the fuzzer code and run some loops (which likely don't find any new bugs via fuzzing, but at least we know that the code can still be run). A nice side-effect of this test is that the leak tests are enabled here, so we should now notice some of the memory leaks in our code base earlier. Message-Id: <20200716100950.27396-1-thuth@redhat.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-17qom: Plug memory leak in "info qom-tree"Markus Armbruster1-2/+4
Commit e8c9e65816 "qom: Make "info qom-tree" show children sorted" created a memory leak, because I didn't realize object_get_canonical_path_component()'s value needs to be freed. Reproducer: $ qemu-system-x86_64 -nodefaults -display none -S -monitor stdio QEMU 5.0.50 monitor - type 'help' for more information (qemu) info qom-tree This leaks some 4500 path components, 12-13 characters on average, i.e. roughly 100kBytes depending on the allocator. A couple of hundred "info qom-tree" here, a couple of hundred there, and soon enough we're talking about real memory. Plug the leak. Fixes: e8c9e65816f5dbfe18ad3b2be938d0d8192d459a Signed-off-by: Markus Armbruster <armbru@redhat.com> Reported-by: Reviewed-by: Li Qiang <liq3ea@gmail.com> [sent same patch] Message-Id: <20200714160202.3121879-3-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-17configure: Fix for running with --enable-werror on macOSThomas Huth1-1/+1
The configure script currently refuses to succeed when run on macOS with --enable-werror: ERROR: configure test passed without -Werror but failed with -Werror. The information in config.log indicates: config-temp/qemu-conf.c:3:55: error: control reaches end of non-void function [-Werror,-Wreturn-type] static void *f(void *p) { pthread_setname_np("QEMU"); } ^ And indeed, the return statement is missing here. Fixes: 479a57475e ("util: Implement debug-threads for macOS") Message-Id: <20200716055655.24507-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-17fuzz: Expect the cmdline in a freeable GStringAlexander Bulekov4-15/+14
In the initial FuzzTarget, get_init_cmdline returned a char *. With this API, we had no guarantee about where the string came from. For example, i440fx-qtest-reboot-fuzz simply returned a pointer to a string literal, while the QOS-based targets build the arguments out in a GString an return the gchar *str pointer. Since we did not try to free the cmdline, we have a leak for any targets that do not simply return string literals. Clean up this mess by forcing fuzz-targets to return a GString, that we can free. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20200714174616.20709-1-alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-17tests: qmp-cmd-test: fix memory leakLi Qiang1-0/+13
Properly free each test response to avoid memory leak and separate qtest_qmp() calls with spare lines, in a consistent manner. Fixes: 5b88849e7b9("tests/qmp-cmd-test: Add qmp/object-add-failure-modes") Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Li Qiang <liq3ea@163.com> Message-Id: <20200715154117.15456-1-liq3ea@163.com> Fixes: 9fc719b869 ("tests/qmp-cmd-test: Add qmp/object-add-duplicate-id") Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-17qtest: bios-tables-test: fix a memory leakLi Qiang1-0/+1
Fixes: 5da7c35e25a("bios-tables-test: Add Q35/TPM-TIS test") Signed-off-by: Li Qiang <liq3ea@163.com> Message-Id: <20200714153536.66060-1-liq3ea@163.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-16tcg/cpu-exec: precise single-stepping after an exceptionLuc Michel1-0/+11
When single-stepping with a debugger attached to QEMU, and when an exception is raised, the debugger misses the first instruction after the exception: $ qemu-system-aarch64 -M virt -display none -cpu cortex-a53 -s -S $ aarch64-linux-gnu-gdb GNU gdb (GDB) 9.2 [...] (gdb) tar rem :1234 Remote debugging using :1234 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x0000000000000000 in ?? () (gdb) # writing nop insns to 0x200 and 0x204 (gdb) set *0x200 = 0xd503201f (gdb) set *0x204 = 0xd503201f (gdb) # 0x0 address contains 0 which is an invalid opcode. (gdb) # The CPU should raise an exception and jump to 0x200 (gdb) si 0x0000000000000204 in ?? () With this commit, the same run steps correctly on the first instruction of the exception vector: (gdb) si 0x0000000000000200 in ?? () Buglink: https://bugs.launchpad.net/qemu/+bug/757702 Signed-off-by: Luc Michel <luc.michel@greensocs.com> Message-Id: <20200716193947.3058389-1-luc.michel@greensocs.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-07-16tcg: Save/restore vecop_list around minmax fallbackRichard Henderson1-0/+2
Forgetting this asserts when tcg_gen_cmp_vec is called from within tcg_gen_cmpsel_vec. Fixes: 72b4c792c7a Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-07-16i386: hvf: Explicitly set CR4 guest/host maskRoman Bolshakov1-0/+1
Removal of register reset omitted initialization of CR4 guest/host mask. x86_64 guests aren't booting without it. Fixes: 5009ef22c6bb2 ("i386: hvf: Don't duplicate register reset") Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Message-Id: <20200714090726.41082-1-r.bolshakov@yadro.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-07-16hw/i2c: Document the I2C qdev helpersPhilippe Mathieu-Daudé1-0/+48
In commit d88c42ff2c we added new prototype but neglected to add their documentation. Fix that. Reported-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Corey Minyard <cminyard@mvista.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200705224154.16917-6-f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-16hw/i2c: Rename i2c_create_slave() as i2c_slave_create_simple()Philippe Mathieu-Daudé16-53/+54
We use "create_simple" names for functions that allocate, initialize, configure and realize device objects: pci_create_simple(), isa_create_simple(), usb_create_simple(). For consistency, rename i2c_create_slave() as i2c_slave_create_simple(). Since we have to update all the callers, also let it return a I2CSlave object. Suggested-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Corey Minyard <cminyard@mvista.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200705224154.16917-5-f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-16hw/i2c: Rename i2c_realize_and_unref() as i2c_slave_realize_and_unref()Philippe Mathieu-Daudé3-8/+10
The other i2c functions are called i2c_slave_FOO(). Rename as i2c_slave_realize_and_unref() to be consistent. Suggested-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200705224154.16917-4-f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-16hw/i2c: Rename i2c_try_create_slave() as i2c_slave_new()Philippe Mathieu-Daudé3-9/+8
We use "new" names for functions that allocate and initialize device objects: pci_new(), isa_new(), usb_new(). Let's call this one i2c_slave_new(). Since we have to update all the callers, also let it return a I2CSlave object. Suggested-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200705224154.16917-3-f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-16hw/i2c/aspeed_i2c: Simplify aspeed_i2c_get_bus()Philippe Mathieu-Daudé3-38/+37
All the callers of aspeed_i2c_get_bus() have a AspeedI2CState and cast it to a DeviceState with DEVICE(), then aspeed_i2c_get_bus() cast the DeviceState to an AspeedI2CState with ASPEED_I2C()... Simplify aspeed_i2c_get_bus() callers by using AspeedI2CState argument. Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200705224154.16917-2-f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-16hw/i2c/Kconfig: Add an entry for the SMBusPhilippe Mathieu-Daudé2-3/+8
The System Management Bus is more or less a derivative of the I2C bus, thus the Kconfig entry depends of I2C. Not all boards providing an I2C bus support SMBus. Use two different Kconfig entries to be able to select I2C without selecting SMBus. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191231183216.6781-6-philmd@redhat.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-16target/i386: add the missing vmx features for Skylake-Server and ↵Chenyi Qiang1-0/+14
Cascadelake-Server CPU models Add the missing vmx features in Skylake-Server and Cascadelake-Server CPU models based on the output of Paolo's script. Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Message-Id: <20200714084148.26690-4-chenyi.qiang@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-07-16target/i386: fix model number and add missing features for Icelake-Server ↵Chenyi Qiang1-0/+14
CPU model Add the missing features(sha_ni, avx512ifma, rdpid, fsrm, vmx-rdseed-exit, vmx-pml, vmx-eptp-switching) and change the model number to 106 in the Icelake-Server-v4 CPU model. Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Message-Id: <20200714084148.26690-3-chenyi.qiang@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-07-16target/i386: add fast short REP MOV supportChenyi Qiang2-1/+3
For CPUs support fast short REP MOV[CPUID.(EAX=7,ECX=0):EDX(bit4)], e.g Icelake and Tigerlake, expose it to the guest VM. Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Message-Id: <20200714084148.26690-2-chenyi.qiang@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-07-16i386/cpu: Don't add unavailable_features to env->user_featuresXiaoyao Li1-1/+0
Features unavailable due to absent of their dependent features should not be added to env->user_features. env->user_features only contains the feature explicity specified with -feature/+feature by user. Fixes: 99e24dbdaa68 ("target/i386: introduce generic feature dependency mechanism") Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-Id: <20200713174436.41070-3-xiaoyao.li@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-07-16i368/cpu: Clear env->user_features after loading versioned CPU modelXiaoyao Li1-0/+7
Features defined in versioned CPU model are recorded in env->user_features since they are updated as property. It's unwated because they are not user specified. Simply clear env->user_features as a fix. It won't clear user specified features because user specified features are filled to env->user_features later in x86_cpu_expand_features(). Cc: Chenyi Qiang <chenyi.qiang@intel.com> Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-Id: <20200713174436.41070-2-xiaoyao.li@intel.com> [ehabkost: fix coding style] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-07-16usb: fix storage regressionGerd Hoffmann1-2/+1
Fix the contition to figure whenever we need to wait for more data or not. Simply check the mode, if we are not in DATAIN state any more we are done already and don't need to go ASYNC. Fixes: 7ad3d51ebb8a ("usb: add short-packet handling to usb-storage driver") Reported-by: Sai Pavan Boddu <saipava@xilinx.com> Tested-by: Paul Zimmerman <pauldzim@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200713062712.1476-1-kraxel@redhat.com
2020-07-16vfio: fix use-after-free in displayGerd Hoffmann1-0/+1
Calling ramfb_display_update() might replace the DisplaySurface with the boot display, which in turn will free the currently active DisplaySurface. So clear our DisplaySurface pinter (dpy->region.surface pointer) to (a) avoid use-after-free and (b) force replacing the boot display with the real display when switching back. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Message-id: 20200713124520.23266-1-kraxel@redhat.com
2020-07-15tests: tpm: Skip over pcrUpdateCounter byte in result comparisonStefan Berger1-1/+5
The TPM 2 code in libtpms was fixed to handle the PCR 'TCB group' according to the PCClient profile. The change of the PCRs belonging to the 'TCB group' now affects the pcrUpdateCounter in the TPM2_PCRRead() responses where its value is now different (typically lower by '1') than what it was before. To not fail the tests, we skip the comparison of the 14th byte, which represents the pcrUpdateCounter. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20200707201625.4177419-3-stefanb@linux.vnet.ibm.com
2020-07-15tpm: tpm_spapr: Exit on TPM backend failuresStefan Berger1-1/+4
Exit on TPM backend failures in the same way as the TPM CRB and TIS device models do. With this change we now get an error report when the backend did not start up properly: error: internal error: qemu unexpectedly closed the monitor: 2020-07-07T12:49:28.333928Z qemu-system-ppc64: tpm-emulator: \ TPM result for CMD_INIT: 0x101 operation failed Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20200707201625.4177419-2-stefanb@linux.vnet.ibm.com
2020-07-15Update version for v5.1.0-rc0 releasePeter Maydell1-1/+1
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-15ftgmac100: fix dblac write testerik-smit1-6/+8
The test of the write of the dblac register was testing the old value instead of the new value. This would accept the write of an invalid value but subsequently refuse any following valid writes. Signed-off-by: erik-smit <erik.lucas.smit@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-07-15net: detect errors from probing vnet hdr flag for TAP devicesDaniel P. Berrange6-12/+29
When QEMU sets up a tap based network device backend, it mostly ignores errors reported from various ioctl() calls it makes, assuming the TAP file descriptor is valid. This assumption can easily be violated when the user is passing in a pre-opened file descriptor. At best, the ioctls may fail with a -EBADF, but if the user passes in a bogus FD number that happens to clash with a FD number that QEMU has opened internally for another reason, a wide variety of errnos may result, as the TUNGETIFF ioctl number may map to a completely different command on a different type of file. By ignoring all these errors, QEMU sets up a zombie network backend that will never pass any data. Even worse, when QEMU shuts down, or that network backend is hot-removed, it will close this bogus file descriptor, which could belong to another QEMU device backend. There's no obvious guaranteed reliable way to detect that a FD genuinely is a TAP device, as opposed to a UNIX socket, or pipe, or something else. Checking the errno from probing vnet hdr flag though, does catch the big common cases. ie calling TUNGETIFF will return EBADF for an invalid FD, and ENOTTY when FD is a UNIX socket, or pipe which catches accidental collisions with FDs used for stdio, or monitor socket. Previously the example below where bogus fd 9 collides with the FD used for the chardev saw: $ ./x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hostnet0,fd=9 \ -chardev socket,id=charchannel0,path=/tmp/qga,server,nowait \ -monitor stdio -vnc :0 qemu-system-x86_64: -netdev tap,id=hostnet0,fd=9: TUNGETIFF ioctl() failed: Inappropriate ioctl for device TUNSETOFFLOAD ioctl() failed: Bad address QEMU 2.9.1 monitor - type 'help' for more information (qemu) Warning: netdev hostnet0 has no peer which gives a running QEMU with a zombie network backend. With this change applied we get an error message and QEMU immediately exits before carrying on and making a bigger disaster: $ ./x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hostnet0,fd=9 \ -chardev socket,id=charchannel0,path=/tmp/qga,server,nowait \ -monitor stdio -vnc :0 qemu-system-x86_64: -netdev tap,id=hostnet0,vhost=on,fd=9: Unable to query TUNGETIFF on FD 9: Inappropriate ioctl for device Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Tested-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-id: 20171027085548.3472-1-berrange@redhat.com [lv: to simplify, don't check on EINVAL with TUNGETIFF as it exists since v2.6.27] Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-07-15net: check if the file descriptor is valid before using itLaurent Vivier5-39/+79
qemu_set_nonblock() checks that the file descriptor can be used and, if not, crashes QEMU. An assert() is used for that. The use of assert() is used to detect programming error and the coredump will allow to debug the problem. But in the case of the tap device, this assert() can be triggered by a misconfiguration by the user. At startup, it's not a real problem, but it can also happen during the hot-plug of a new device, and here it's a problem because we can crash a perfectly healthy system. For instance: # ip link add link virbr0 name macvtap0 type macvtap mode bridge # ip link set macvtap0 up # TAP=/dev/tap$(ip -o link show macvtap0 | cut -d: -f1) # qemu-system-x86_64 -machine q35 -device pcie-root-port,id=pcie-root-port-0 -monitor stdio 9<> $TAP (qemu) netdev_add type=tap,id=hostnet0,vhost=on,fd=9 (qemu) device_add driver=virtio-net-pci,netdev=hostnet0,id=net0,bus=pcie-root-port-0 (qemu) device_del net0 (qemu) netdev_del hostnet0 (qemu) netdev_add type=tap,id=hostnet1,vhost=on,fd=9 qemu-system-x86_64: .../util/oslib-posix.c:247: qemu_set_nonblock: Assertion `f != -1' failed. Aborted (core dumped) To avoid that, add a function, qemu_try_set_nonblock(), that allows to report the problem without crashing. In the same way, we also update the function for vhostfd in net_init_tap_one() and for fd in net_init_socket() (both descriptors are provided by the user and can be wrong). Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-07-15qemu-options.hx: Clean up and fix typo for colo-compareZhang Chen1-16/+16
Fix some typo and optimized some descriptions. Signed-off-by: Zhang Chen <chen.zhang@intel.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-07-15net/colo-compare.c: Expose compare "max_queue_size" to usersZhang Chen2-3/+45
This patch allow users to set the "max_queue_size" according to their environment. Signed-off-by: Zhang Chen <chen.zhang@intel.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-07-15hw/net: Added CSO for IPv6Andrew1-3/+12
Added fix for checksum offload for IPv6 if a backend doesn't have a virtual header. This patch is a part of IPv6 fragmentation. Signed-off-by: Andrew Melnychenko <andrew@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-07-15virtio-net: fix removal of failover deviceJuan Quintela1-0/+1
If you have a networking device and its virtio failover device, and you remove them in this order: - virtio device - the real device You get qemu crash. See bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1820120 Bug exist on qemu 4.2 and 5.0. But in 5.0 don't shows because commit 77b06bba62034a87cc61a9c8de1309ae3e527d97 somehow papers over it. CC: Jason Wang <jasowang@redhat.com> CC: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>