bwlp/qemu.git/hw/core, branch spice_video_codecs

Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu into staging

2022-11-07T23:43:56+00:00

pci,pc,virtio: features, tests, fixes, cleanups lots of acpi rework first version of biosbits infrastructure ASID support in vhost-vdpa core_count2 support in smbios PCIe DOE emulation virtio vq reset HMAT support part of infrastructure for viommu support in vhost-vdpa VTD PASID support fixes, tests all over the place Signed-off-by: Michael S. Tsirkin # -----BEGIN PGP SIGNATURE----- # # iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmNpXDkPHG1zdEByZWRo # YXQuY29tAAoJECgfDbjSjVRpD0AH/2G8ZPrgrxJC9y3uD5/5J6QRzO+TsDYbg5ut # uBf4rKSHHzcu6zdyAfsrhbAKKzyD4HrEGNXZrBjnKM1xCiB/SGBcDIWntwrca2+s # 5Dpbi4xvd4tg6tVD4b47XNDCcn2uUbeI0e2M5QIbtCmzdi/xKbFAfl5G8DQp431X # Kmz79G4CdKWyjVlM0HoYmdCw/4FxkdjD02tE/Uc5YMrePNaEg5Bw4hjCHbx1b6ur # 6gjeXAtncm9s4sO0l+sIdyiqlxiTry9FSr35WaQ0qPU+Og5zaf1EiWfdl8TRo4qU # EAATw5A4hyw11GfOGp7oOVkTGvcNB/H7aIxD7emdWZV8+BMRPKo= # =zTCn # -----END PGP SIGNATURE----- # gpg: Signature made Mon 07 Nov 2022 14:27:53 EST # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin " [full] # gpg: aka "Michael S. Tsirkin " [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 * tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (83 commits) checkpatch: better pattern for inline comments hw/virtio: introduce virtio_device_should_start tests/acpi: update tables for new core count test bios-tables-test: add test for number of cores > 255 tests/acpi: allow changes for core_count2 test bios-tables-test: teach test to use smbios 3.0 tables hw/smbios: add core_count2 to smbios table type 4 vhost-user: Support vhost_dev_start vhost: Change the sequence of device start intel-iommu: PASID support intel-iommu: convert VTD_PE_GET_FPD_ERR() to be a function intel-iommu: drop VTDBus intel-iommu: don't warn guest errors when getting rid2pasid entry vfio: move implement of vfio_get_xlat_addr() to memory.c tests: virt: Update expected *.acpihmatvirt tables tests: acpi: aarch64/virt: add a test for hmat nodes with no initiators hw/arm/virt: Enable HMAT on arm virt machine tests: Add HMAT AArch64/virt empty table files tests: acpi: q35: update expected blobs *.hmat-noinitiators expected HMAT: tests: acpi: q35: add test for hmat nodes without initiators ... Signed-off-by: Stefan Hajnoczi

hmat acpi: Don't require initiator value in -numa

2022-11-07T19:08:17+00:00

The "Memory Proximity Domain Attributes" structure of the ACPI HMAT has a "Processor Proximity Domain Valid" flag that is currently always set because Qemu -numa requires an initiator=X value when hmat=on. Unsetting this flag allows to create more complex memory topologies by having multiple best initiators for a single memory target. This patch allows -numa without initiator=X when hmat=on by keeping the default value MAX_NODES in numa_state->nodes[i].initiator. All places reading numa_state->nodes[i].initiator already check whether it's different from MAX_NODES before using it. Tested with qemu-system-x86_64 -accel kvm \ -machine pc,hmat=on \ -drive if=pflash,format=raw,file=./OVMF.fd \ -drive media=disk,format=qcow2,file=efi.qcow2 \ -smp 4 \ -m 3G \ -object memory-backend-ram,size=1G,id=ram0 \ -object memory-backend-ram,size=1G,id=ram1 \ -object memory-backend-ram,size=1G,id=ram2 \ -numa node,nodeid=0,memdev=ram0,cpus=0-1 \ -numa node,nodeid=1,memdev=ram1,cpus=2-3 \ -numa node,nodeid=2,memdev=ram2 \ -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=10 \ -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=10485760 \ -numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,latency=20 \ -numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=5242880 \ -numa hmat-lb,initiator=0,target=2,hierarchy=memory,data-type=access-latency,latency=30 \ -numa hmat-lb,initiator=0,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=1048576 \ -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-latency,latency=20 \ -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=5242880 \ -numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-latency,latency=10 \ -numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=10485760 \ -numa hmat-lb,initiator=1,target=2,hierarchy=memory,data-type=access-latency,latency=30 \ -numa hmat-lb,initiator=1,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=1048576 which reports NUMA node2 at same distance from both node0 and node1 as seen in lstopo: Machine (2966MB total) + Package P#0 NUMANode P#2 (979MB) Group0 NUMANode P#0 (980MB) Core P#0 + PU P#0 Core P#1 + PU P#1 Group0 NUMANode P#1 (1007MB) Core P#2 + PU P#2 Core P#3 + PU P#3 Before this patch, we had to add ",initiator=X" to "-numa node,nodeid=2,memdev=ram2". The lstopo output difference between initiator=1 and no initiator is: @@ -1,10 +1,10 @@ Machine (2966MB total) + Package P#0 + NUMANode P#2 (979MB) Group0 NUMANode P#0 (980MB) Core P#0 + PU P#0 Core P#1 + PU P#1 Group0 NUMANode P#1 (1007MB) - NUMANode P#2 (979MB) Core P#2 + PU P#2 Core P#3 + PU P#3 Corresponding changes in the HMAT MPDA structure: @@ -49,10 +49,10 @@ [078h 0120 2] Structure Type : 0000 [Memory Proximity Domain Attributes] [07Ah 0122 2] Reserved : 0000 [07Ch 0124 4] Length : 00000028 -[080h 0128 2] Flags (decoded below) : 0001 - Processor Proximity Domain Valid : 1 +[080h 0128 2] Flags (decoded below) : 0000 + Processor Proximity Domain Valid : 0 [082h 0130 2] Reserved1 : 0000 -[084h 0132 4] Attached Initiator Proximity Domain : 00000001 +[084h 0132 4] Attached Initiator Proximity Domain : 00000080 [088h 0136 4] Memory Proximity Domain : 00000002 [08Ch 0140 4] Reserved2 : 00000000 [090h 0144 8] Reserved3 : 0000000000000000 Final HMAT SLLB structures: [0A0h 0160 2] Structure Type : 0001 [System Locality Latency and Bandwidth Information] [0A2h 0162 2] Reserved : 0000 [0A4h 0164 4] Length : 00000040 [0A8h 0168 1] Flags (decoded below) : 00 Memory Hierarchy : 0 [0A9h 0169 1] Data Type : 00 [0AAh 0170 2] Reserved1 : 0000 [0ACh 0172 4] Initiator Proximity Domains # : 00000002 [0B0h 0176 4] Target Proximity Domains # : 00000003 [0B4h 0180 4] Reserved2 : 00000000 [0B8h 0184 8] Entry Base Unit : 0000000000002710 [0C0h 0192 4] Initiator Proximity Domain List : 00000000 [0C4h 0196 4] Initiator Proximity Domain List : 00000001 [0C8h 0200 4] Target Proximity Domain List : 00000000 [0CCh 0204 4] Target Proximity Domain List : 00000001 [0D0h 0208 4] Target Proximity Domain List : 00000002 [0D4h 0212 2] Entry : 0001 [0D6h 0214 2] Entry : 0002 [0D8h 0216 2] Entry : 0003 [0DAh 0218 2] Entry : 0002 [0DCh 0220 2] Entry : 0001 [0DEh 0222 2] Entry : 0003 [0E0h 0224 2] Structure Type : 0001 [System Locality Latency and Bandwidth Information] [0E2h 0226 2] Reserved : 0000 [0E4h 0228 4] Length : 00000040 [0E8h 0232 1] Flags (decoded below) : 00 Memory Hierarchy : 0 [0E9h 0233 1] Data Type : 03 [0EAh 0234 2] Reserved1 : 0000 [0ECh 0236 4] Initiator Proximity Domains # : 00000002 [0F0h 0240 4] Target Proximity Domains # : 00000003 [0F4h 0244 4] Reserved2 : 00000000 [0F8h 0248 8] Entry Base Unit : 0000000000000001 [100h 0256 4] Initiator Proximity Domain List : 00000000 [104h 0260 4] Initiator Proximity Domain List : 00000001 [108h 0264 4] Target Proximity Domain List : 00000000 [10Ch 0268 4] Target Proximity Domain List : 00000001 [110h 0272 4] Target Proximity Domain List : 00000002 [114h 0276 2] Entry : 000A [116h 0278 2] Entry : 0005 [118h 0280 2] Entry : 0001 [11Ah 0282 2] Entry : 0005 [11Ch 0284 2] Entry : 000A [11Eh 0286 2] Entry : 0001 Signed-off-by: Brice Goglin Signed-off-by: Hesham Almatary Reviewed-by: Jingqi Liu Message-Id: <20221027100037.251-2-hesham.almatary@huawei.com> Tested-by: Yicong Yang Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

virtio: core: vq reset feature negotation support

2022-11-07T18:12:20+00:00

A a new command line parameter "queue_reset" is added. Meanwhile, the vq reset feature is disabled for pre-7.2 machines. Signed-off-by: Kangjie Xu Signed-off-by: Xuan Zhuo Acked-by: Jason Wang Message-Id: <20221017092558.111082-5-xuanzhuo@linux.alibaba.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

module: add Error arguments to module_load and module_load_qom

2022-11-06T08:48:50+00:00

improve error handling during module load, by changing: bool module_load(const char *prefix, const char *lib_name); void module_load_qom(const char *type); to: int module_load(const char *prefix, const char *name, Error **errp); int module_load_qom(const char *type, Error **errp); where the return value is: -1 on module load error, and errp is set with the error 0 on module or one of its dependencies are not installed 1 on module load success 2 on module load success (module already loaded or built-in) module_load_qom_one has been introduced in: commit 28457744c345 ("module: qom module support"), which built on top of module_load_one, but discarded the bool return value. Restore it. Adapt all callers to emit errors, or ignore them, or fail hard, as appropriate in each context. Replace the previous emission of errors via fprintf in _some_ error conditions with Error and error_report, so as to emit to the appropriate target. A memory leak is also fixed as part of the module_load changes. audio: when attempting to load an audio module, report module load errors. Note that still for some callers, a single issue may generate multiple error reports, and this could be improved further. Regarding the audio code itself, audio_add() seems to ignore errors, and this should probably be improved. block: when attempting to load a block module, report module load errors. For the code paths that already use the Error API, take advantage of those to report module load errors into the Error parameter. For the other code paths, we currently emit the error, but this could be improved further by adding Error parameters to all possible code paths. console: when attempting to load a display module, report module load errors. qdev: when creating a new qdev Device object (DeviceState), report load errors. If a module cannot be loaded to create that device, now abort execution (if no CONFIG_MODULE) or exit (if CONFIG_MODULE). qom/object.c: when initializing a QOM object, or looking up class_by_name, report module load errors. qtest: when processing the "module_load" qtest command, report errors in the load of the module. Signed-off-by: Claudio Fontana Reviewed-by: Richard Henderson Message-Id: <20220929093035.4231-4-cfontana@suse.de> Signed-off-by: Paolo Bonzini

module: rename module_load_one to module_load

2022-11-06T08:48:50+00:00

Signed-off-by: Claudio Fontana Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson Message-Id: <20220929093035.4231-3-cfontana@suse.de> Signed-off-by: Paolo Bonzini

Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into staging

2022-10-30T19:07:25+00:00

Pull request # -----BEGIN PGP SIGNATURE----- # # iQEzBAABCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmNZg14ACgkQnKSrs4Gr # c8hwwwf/Udbnt6n4SShezEIYRe0udLvuyo1HwcMNLWjllHLfp/yNDcPsGk+r13Ue # TxrvbVaucxB5RPdN67KmzPyu+wPM/o0nij7c4CkBvwNPXmfUCF97Lj0prEL+ZeHp # HmNg08FRfHM2vKMFyJXqDAidBecUDizLrP9C3nc/LAF6fr9ds+vfFuB/12eSXvZ+ # RLnaAj7KLt2MzkgWbDiC6066TPZWCcwFJmc0zkCAthCepokDrKfSHc+0u9U/NXA9 # Qv7qKcEBYq3vP3SCvDtbKU3Ig4CoiwO3A3O9wZTypamU2816H9HtEJ5NPtjNUFPF # dm3siyKODbDx4mzba/Xv/26lHGSsJA== # =bmGV # -----END PGP SIGNATURE----- # gpg: Signature made Wed 26 Oct 2022 14:58:38 EDT # gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi " [ultimate] # gpg: aka "Stefan Hajnoczi " [ultimate] # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * tag 'block-pull-request' of https://gitlab.com/stefanha/qemu: virtio-blk: use BDRV_REQ_REGISTERED_BUF optimization hint blkio: implement BDRV_REQ_REGISTERED_BUF optimization stubs: add qemu_ram_block_from_host() and qemu_ram_get_fd() exec/cpu-common: add qemu_ram_get_fd() block: add BlockRAMRegistrar numa: use QLIST_FOREACH_SAFE() for RAM block notifiers block: return errors from bdrv_register_buf() block: add BDRV_REQ_REGISTERED_BUF request flag block: use BdrvRequestFlags type for supported flag fields block: pass size to bdrv_unregister_buf() numa: call ->ram_block_removed() in ram_block_notifer_remove() blkio: add libblkio block driver coroutine: add flag to re-queue at front of CoQueue Signed-off-by: Stefan Hajnoczi

reset: allow registering handlers that aren't called by snapshot loading

2022-10-27T10:34:31+00:00

Snapshot loading only expects to call deterministic handlers, not non-deterministic ones. So introduce a way of registering handlers that won't be called when reseting for snapshots. Signed-off-by: Jason A. Donenfeld Message-id: 20221025004327.568476-2-Jason@zx2c4.com [PMM: updated json doc comment with Markus' text; fixed checkpatch style nit] Reviewed-by: Peter Maydell Signed-off-by: Peter Maydell

hw/core/resettable: fix reset level counting

2022-10-27T09:27:23+00:00

The code for handling the reset level count in the Resettable code has two issues: The reset count is only decremented for the 1->0 case. This means that if there's ever a nested reset that takes the count to 2 then it will never again be decremented. Eventually the count will exceed the '50' limit in resettable_phase_enter() and QEMU will trip over the assertion failure. The repro case in issue 1266 is an example of this that happens now the SCSI subsystem uses three-phase reset. Secondly, the count is decremented only after the exit phase handler is called. Moving the reset count decrement from "just after" to "just before" calling the exit phase handler allows resettable_is_in_reset() to return false during the handler execution. This simplifies reset handling in resettable devices. Typically, a function that updates the device state will just need to read the current reset state and not anymore treat the "in a reset-exit transition" as a special case. Note that the semantics change to the *_is_in_reset() functions will have no effect on the current codebase, because only two devices (hw/char/cadence_uart.c and hw/misc/zynq_sclr.c) currently call those functions, and in neither case do they do it from the device's exit phase methed. Fixes: 4a5fc890 ("scsi: Use device_cold_reset() and bus_cold_reset()") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1266 Signed-off-by: Damien Hedde Signed-off-by: Peter Maydell Reported-by: Michael Peter Reviewed-by: Philippe Mathieu-Daudé Message-id: 20221020142749.3357951-1-peter.maydell@linaro.org Buglink: https://bugs.launchpad.net/qemu/+bug/1905297 Reported-by: Michael Peter [PMM: adjust the docs paragraph changed to get the name of the 'enter' phase right and to clarify exactly when the count is adjusted; rewrite the commit message] Signed-off-by: Peter Maydell

numa: use QLIST_FOREACH_SAFE() for RAM block notifiers

2022-10-26T18:56:42+00:00

Make list traversal work when a callback removes a notifier mid-traversal. This is a cleanup to prevent bugs in the future. Signed-off-by: Stefan Hajnoczi Reviewed-by: David Hildenbrand Message-id: 20221013185908.1297568-9-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi

numa: call ->ram_block_removed() in ram_block_notifer_remove()

2022-10-26T18:56:42+00:00

When a RAMBlockNotifier is added, ->ram_block_added() is called with all existing RAMBlocks. There is no equivalent ->ram_block_removed() call when a RAMBlockNotifier is removed. The util/vfio-helpers.c code (the sole user of RAMBlockNotifier) is fine with this asymmetry because it does not rely on RAMBlockNotifier for cleanup. It walks its internal list of DMA mappings and unmaps them by itself. Future users of RAMBlockNotifier may not have an internal data structure that records added RAMBlocks so they will need ->ram_block_removed() callbacks. This patch makes ram_block_notifier_remove() symmetric with respect to callbacks. Now util/vfio-helpers.c needs to unmap remaining DMA mappings after ram_block_notifier_remove() has been called. This is necessary since users like block/nvme.c may create additional DMA mappings that do not originate from the RAMBlockNotifier. Reviewed-by: David Hildenbrand Signed-off-by: Stefan Hajnoczi Message-id: 20221013185908.1297568-4-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi