aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2023-12-22next-cube.c: move static phase variable to NextRtcMark Cave-Ayland1-15/+16
The phase variable represents part of the state machine used to clock data out of the NextRtc device. Note that this is a migration break for the NeXTRtc struct, but as nothing will currently boot then we simply bump the migration version for now. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20231220131641.592826-8-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2023-12-22next-cube.c: move static led variable to NeXTPCMark Cave-Ayland1-6/+7
The state of the led is stored in the SCR2 register which is part of the NeXTPC device. Note that this is a migration break for the NeXTPC device, but as nothing will currently boot then we simply bump the migration version for now. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20231220131641.592826-7-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2023-12-22next-cube.c: update and improve dma_opsMark Cave-Ayland1-37/+63
Rename dma_ops to next_dma_ops and the read/write functions to next_dma_read() and next_dma_write() respectively, mark next_dma_ops as DEVICE_BIG_ENDIAN and also improve the consistency of the val variable in next_dma_read() and next_dma_write(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20231220131641.592826-6-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2023-12-22next-cube.c: update scr_ops to properly use modern memory APIMark Cave-Ayland1-100/+55
The old QEMU memory accessors used in the original NextCube patch series had separate functions for 1, 2 and 4 byte accessors. When the series was finally merged a simple wrapper function was written to dispatch the memory accesses using the original functions. Convert scr_ops to use the memory API directly renaming it to next_scr_ops, marking it as DEVICE_BIG_ENDIAN, and handling any unaligned accesses. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20231220131641.592826-5-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2023-12-22next-cube.c: update mmio_ops to properly use modern memory APIMark Cave-Ayland1-111/+45
The old QEMU memory accessors used in the original NextCube patch series had separate functions for 1, 2 and 4 byte accessors. When the series was finally merged a simple wrapper function was written to dispatch the memory accesses using the original functions. Convert mmio_ops to use the memory API directly renaming it to next_mmio_ops, marking it as DEVICE_BIG_ENDIAN, and handling any unaligned accesses. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20231220131641.592826-4-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2023-12-22next-cube.c: don't pulse SCSI DMA IRQ upon reception of FLUSH commandMark Cave-Ayland1-1/+0
Normally a DMA FLUSH command is used to ensure that data is completely written to the device and/or memory, so remove the pulse of the SCSI DMA IRQ if a DMA FLUSH command is received. This enables the NeXT ROM monitor to start to load from a SCSI disk. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20231220131641.592826-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2023-12-22next-cube.c: add dummy Ethernet register to allow diagnostic to timeoutMark Cave-Ayland1-0/+4
Add a dummy register at address 0x6000 in the MMIO memory region to allow the initial diagnostic test to timeout rather than getting stuck in a loop continuously writing "en_write: tx not ready" to the console. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20231220131641.592826-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2023-12-21virtio-blk: add iothread-vq-mapping parameterStefan Hajnoczi3-50/+200
Add the iothread-vq-mapping parameter to assign virtqueues to IOThreads. Store the vq:AioContext mapping in the new struct VirtIOBlockDataPlane->vq_aio_context[] field and refactor the code to use the per-vq AioContext instead of the BlockDriverState's AioContext. Reimplement --device virtio-blk-pci,iothread= and non-IOThread mode by assigning all virtqueues to the IOThread and main loop's AioContext in vq_aio_context[], respectively. The comment in struct VirtIOBlockDataPlane about EventNotifiers is stale. Remove it. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231220134755.814917-5-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21qdev: add IOThreadVirtQueueMappingList property typeStefan Hajnoczi1-0/+46
virtio-blk and virtio-scsi devices will need a way to specify the mapping between IOThreads and virtqueues. At the moment all virtqueues are assigned to a single IOThread or the main loop. This single thread can be a CPU bottleneck, so it is necessary to allow finer-grained assignment to spread the load. Introduce DEFINE_PROP_IOTHREAD_VQ_MAPPING_LIST() so devices can take a parameter that maps virtqueues to IOThreads. The command-line syntax for this new property is as follows: --device '{"driver":"foo","iothread-vq-mapping":[{"iothread":"iothread0","vqs":[0,1,2]},...]}' IOThreads are specified by name and virtqueues are specified by 0-based index. It will be common to simply assign virtqueues round-robin across a set of IOThreads. A convenient syntax that does not require specifying individual virtqueue indices is available: --device '{"driver":"foo","iothread-vq-mapping":[{"iothread":"iothread0"},{"iothread":"iothread1"},...]}' Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231220134755.814917-4-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21qdev-properties: alias all object class propertiesStefan Hajnoczi1-8/+10
qdev_alias_all_properties() aliases a DeviceState's qdev properties onto an Object. This is used for VirtioPCIProxy types so that --device virtio-blk-pci has properties of its embedded --device virtio-blk-device object. Currently this function is implemented using qdev properties. Change the function to use QOM object class properties instead. This works because qdev properties create QOM object class properties, but it also catches any QOM object class-only properties that have no qdev properties. This change ensures that properties of devices are shown with --device foo,\? even if they are QOM object class properties. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231220134755.814917-2-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21scsi: remove outdated AioContext lock commentStefan Hajnoczi1-1/+0
The SCSI subsystem no longer uses the AioContext lock. Request processing runs exclusively in the BlockBackend's AioContext since "scsi: only access SCSIDevice->requests from one thread" and hence the lock is unnecessary. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-ID: <20231205182011.1976568-13-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21scsi: remove AioContext lockingStefan Hajnoczi3-46/+5
The AioContext lock no longer has any effect. Remove it. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-ID: <20231205182011.1976568-9-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21block: remove AioContext lockingStefan Hajnoczi4-47/+2
This is the big patch that removes aio_context_acquire()/aio_context_release() from the block layer and affected block layer users. There isn't a clean way to split this patch and the reviewers are likely the same group of people, so I decided to do it in one patch. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org> Message-ID: <20231205182011.1976568-7-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21scsi: assert that callbacks run in the correct AioContextStefan Hajnoczi1-0/+14
Since the removal of AioContext locking, the correctness of the code relies on running requests from a single AioContext at any given time. Add assertions that verify that callbacks are invoked in the correct AioContext. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231205182011.1976568-3-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21virtio-scsi: replace AioContext lock with tmf_bh_lockStefan Hajnoczi1-21/+41
Protect the Task Management Function BH state with a lock. The TMF BH runs in the main loop thread. An IOThread might process a TMF at the same time as the TMF BH is running. Therefore tmf_bh_list and tmf_bh must be protected by a lock. Run TMF request completion in the IOThread using aio_wait_bh_oneshot(). This avoids more locking to protect the virtqueue and SCSI layer state. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231205182011.1976568-2-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21scsi: don't lock AioContext in I/O code pathStefan Hajnoczi2-40/+3
blk_aio_*() doesn't require the AioContext lock and the SCSI subsystem's internal state also does not anymore. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Acked-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231204164259.1515217-4-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21virtio-scsi: don't lock AioContext around ↵Stefan Hajnoczi1-7/+1
virtio_queue_aio_attach_host_notifier() virtio_queue_aio_attach_host_notifier() does not require the AioContext lock. Stop taking the lock and add an explicit smp_wmb() because we were relying on the implicit barrier in the AioContext lock before. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231204164259.1515217-3-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21scsi: only access SCSIDevice->requests from one threadStefan Hajnoczi1-56/+125
Stop depending on the AioContext lock and instead access SCSIDevice->requests from only one thread at a time: - When the VM is running only the BlockBackend's AioContext may access the requests list. - When the VM is stopped only the main loop may access the requests list. These constraints protect the requests list without the need for locking in the I/O code path. Note that multiple IOThreads are not supported yet because the code assumes all SCSIRequests are executed from a single AioContext. Leave that as future work. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-ID: <20231204164259.1515217-2-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21virtio-blk: don't lock AioContext in the submission code pathStefan Hajnoczi1-5/+0
There is no need to acquire the AioContext lock around blk_aio_*() or blk_get_geometry() anymore. I/O plugging (defer_call()) also does not require the AioContext lock anymore. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230914140101.1065008-5-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21virtio-blk: don't lock AioContext in the completion code pathStefan Hajnoczi1-30/+4
Nothing in the completion code path relies on the AioContext lock anymore. Virtqueues are only accessed from one thread at any moment and the s->rq global state is protected by its own lock now. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230914140101.1065008-4-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21virtio-blk: add lock to protect s->rqStefan Hajnoczi1-22/+45
s->rq is accessed from IO_CODE and GLOBAL_STATE_CODE. Introduce a lock to protect s->rq and eliminate reliance on the AioContext lock. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230914140101.1065008-3-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-20Merge tag 'pull-request-2023-12-20' of https://gitlab.com/thuth/qemu into ↵Stefan Hajnoczi11-12/+76
staging * Add compat machines for QEMU 9.0 * Some header clean-ups by Philippe * Restrict type names to alphanumerical range (and a few special characters) * Fix analyze-migration.py script on s390x * Clean up and improve some tests * Document handling of commas in CLI options parameters # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmWCtYsRHHRodXRoQHJl # ZGhhdC5jb20ACgkQLtnXdP5wLbWLnw//cNJrxG0V+j0iakX+C7HRumVrLBDI4KYY # Cp2Hx92SyeQ0Kk8DJS6JueTV0SLjMsV77APu2YPH7ELmPlk+CB9gqmV7xVoYNvsm # QbRPlIjFw8MHLekadc2A+C+pn48tWACoOdBEDIfazKrxybnf0B57RC/fIfMKHjbs # 2ALCoFbbgphs7yWuzTHK8ayKaGMhUVkWfzHQwpnq899olHyZBhkl951uKJA6VmLx # KvggePkpszLjmmXA8MH1hDCcizki31cB0ZKTbQFCyE42s2S3Hvg0GueU90O7Y1cj # lS5tPVQxyEhUYMLL+/hudlf2OYqVn2BalB7ieUQIy6rG8yoc9zxfIKQi0ccl+2oA # s8HRq5S0bSjtilQogU1LQL/Gk6W1/N9MmnhKvCGB+BTK5KX7s4EQk02y9gGZm/8s # pMErMyaXTG4dLiTAK42VgMVDqCYvzBmE+Gj91OmoUR7fb+VMrsWxeBFxMPDn+VtL # TMJegIFsjw2QCSitcU4v+nP0qtKgXGbuZtrGXKabrxH5PmeQFJDSM7TwpTK4qvjK # QMIQKBbz8BfJnUzN8qAaaJEpp1T5tcMJClKtfcgxq/+VyaSaHLmD0cljqBC+g+y7 # FTo+fa7oYx44sAlqapdEXBSGn4T+J26iuCef13CCCiPfYBv/tk3b2E0AWHj4y58I # +VpInjUaPBQ= # =TA1/ # -----END PGP SIGNATURE----- # gpg: Signature made Wed 20 Dec 2023 04:36:11 EST # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "thuth@redhat.com" # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * tag 'pull-request-2023-12-20' of https://gitlab.com/thuth/qemu: tests/unit/test-qmp-event: Replace fixture by global variables tests/unit/test-qmp-event: Simplify event emission check tests/unit/test-qmp-event: Drop superfluous mutex tests/qtest/npcm7xx_pwm-test: Only do full testing in slow mode qemu-options: Clarify handling of commas in options parameters tests/qtest/migration-test: Fix analyze-migration.py for s390x qom/object: Limit type names to alphanumerical and some few special characters tests/unit/test-io-task: Rename "qemu:dummy" to avoid colon in the name memory: Remove "qemu:" prefix from the "qemu:ram-discard-manager" type name hw: Replace anti-social QOM type names (again) docs/system/arm: Fix for rename of type "xlnx.bbram-ctrl" target: Restrict 'sysemu/reset.h' to system emulation hw/s390x/ipl: Remove unused 'exec/exec-all.h' included header hw/misc/mips_itu: Remove unnecessary 'exec/exec-all.h' header hw/ppc/spapr_hcall: Remove unused 'exec/exec-all.h' included header system/qtest: Restrict QTest API to system emulation system/qtest: Include missing 'hw/core/cpu.h' header MAINTAINERS: Add some more vmware-related files to the corresponding section hw: Add compat machines for 9.0 Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-12-20Merge tag 'pull-target-arm-20231219' of ↵Stefan Hajnoczi4-13/+94
https://git.linaro.org/people/pmaydell/qemu-arm into staging target-arm queue: * arm/kvm: drop the split between "common KVM support" and "64-bit KVM support", since 32-bit Arm KVM no longer exists * arm/kvm: clean up APIs to be consistent about CPU arguments * Don't implement *32_EL2 registers when EL1 is AArch64 only * Restrict DC CVAP & DC CVADP instructions to TCG accel * Restrict TCG specific helpers * Propagate MDCR_EL2.HPMN into PMCR_EL0.N * Include missing 'exec/exec-all.h' header * fsl-imx: add simple RTC emulation for i.MX6 and i.MX7 boards # -----BEGIN PGP SIGNATURE----- # # iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmWB6o0ZHHBldGVyLm1h # eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3mxMEACRpRxJ81pLs8fFYC5BgRhU # BCxr+ZqarBygzsH9YWUN2TFFKlEZi7mLu6lzFsfN/qEmYCg8VslPbulQHqcGkx51 # kVxXFp/KuGlKt4zGRagZUJxgYAwwU5mnK6dTZT5/ZF6yWX67dXn8V7MP9lqqEPw5 # 5gut7Mu4f7MiAQbwZY1CWP+iu5uZmdsBuKxA6zkxOWJh/A1SfaqQRO6xVQttLAxS # DPMTpQGmwPS4I+3gGNnqlSu6etp2tdy2K0cW3fhMp6hx70uNMHmFNzRhT/6TaKka # 9AqXQsFHQiFXDGAm6PmCvfQI6KpLljDyNL/TuUkQWi72bGEHjUsJAdG0aXVOa30W # uC7vuJkdZrP/t5P1AkZhWQUrlawDRV2YHNDD+gY4fxJL/STkGyU6M8R1nm1J+InN # n0SeK0VHRC6DRPXCMQhC5QwKUH6ZjFZRs/r2opTu9p+ThQAQRmZBiVfdISCDMYnN # DCiSb78gIFaUkwtiP44qq8MJQjsHnXtTD1Akqyo2fXSKs66jDK9Gnc8gENYdpghe # 7V36bOp6scROHOB2a/r8gT42RKzSN6uh6xByaaToza63/bPgvHnn8vvQQbB01AgX # zJC1xs3dwY8JMyqDefda0K0NDPS8TzNsXYmgxxxcQJpUvB4VVjet9VIMF3T+d8HO # Pas41Z1gsQY+rcaRk/9mPA== # =GWIA # -----END PGP SIGNATURE----- # gpg: Signature made Tue 19 Dec 2023 14:10:05 EST # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [full] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [full] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [full] # gpg: aka "Peter Maydell <peter@archaic.org.uk>" [unknown] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * tag 'pull-target-arm-20231219' of https://git.linaro.org/people/pmaydell/qemu-arm: (43 commits) fsl-imx: add simple RTC emulation for i.MX6 and i.MX7 boards target/arm/helper: Propagate MDCR_EL2.HPMN into PMCR_EL0.N target/arm/tcg: Including missing 'exec/exec-all.h' header target/arm: Restrict DC CVAP & DC CVADP instructions to TCG accel target/arm: Restrict TCG specific helpers target/arm: Don't implement *32_EL2 registers when EL1 is AArch64 only target/arm/kvm: Have kvm_arm_hw_debug_active take a ARMCPU argument target/arm/kvm: Have kvm_arm_handle_debug take a ARMCPU argument target/arm/kvm: Have kvm_arm_handle_dabt_nisv take a ARMCPU argument target/arm/kvm: Have kvm_arm_verify_ext_dabt_pending take a ARMCPU arg target/arm/kvm: Have kvm_arm_[get|put]_virtual_time take ARMCPU argument target/arm/kvm: Have kvm_arm_vcpu_finalize take a ARMCPU argument target/arm/kvm: Have kvm_arm_vcpu_init take a ARMCPU argument target/arm/kvm: Have kvm_arm_pmu_set_irq take a ARMCPU argument target/arm/kvm: Have kvm_arm_pmu_init take a ARMCPU argument target/arm/kvm: Have kvm_arm_pvtime_init take a ARMCPU argument target/arm/kvm: Have kvm_arm_set_device_attr take a ARMCPU argument target/arm/kvm: Have kvm_arm_sve_get_vls take a ARMCPU argument target/arm/kvm: Have kvm_arm_sve_set_vls take a ARMCPU argument target/arm/kvm: Have kvm_arm_add_vcpu_properties take a ARMCPU argument ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-12-20hw/s390x/ipl: Remove unused 'exec/exec-all.h' included headerPhilippe Mathieu-Daudé1-1/+0
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231212113640.30287-4-philmd@linaro.org> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-12-20hw/misc/mips_itu: Remove unnecessary 'exec/exec-all.h' headerPhilippe Mathieu-Daudé1-1/+2
mips_itu.c only requires declarations from "hw/core/cpu.h" and "cpu.h". Avoid including the huge "exec/exec-all.h" header. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231212113640.30287-3-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-12-20hw/ppc/spapr_hcall: Remove unused 'exec/exec-all.h' included headerPhilippe Mathieu-Daudé1-1/+0
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231212113640.30287-2-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-12-20hw: Add compat machines for 9.0Cornelia Huck8-9/+74
Add 9.0 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-ID: <20231120094259.1191804-1-cohuck@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Acked-by: Eric Farman <farman@linux.ibm.com> # s390x Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-12-19hw/ppc/Kconfig: Imply VFIO_PCICédric Le Goater2-1/+37
When the legacy and iommufd backends were introduced, a set of common vfio-pci routines were exported in pci.c for both backends to use : vfio_pci_pre_reset vfio_pci_get_pci_hot_reset_info vfio_pci_host_match vfio_pci_post_reset This introduced a build failure on PPC when --without-default-devices is use because VFIO is always selected in ppc/Kconfig but VFIO_PCI is not. Use an 'imply VFIO_PCI' in ppc/Kconfig and bypass compilation of the VFIO EEH hooks routines defined in hw/ppc/spapr_pci_vfio.c with CONFIG_VFIO_PCI. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio: Introduce a helper function to initialize VFIODeviceZhenzhong Duan5-20/+19
Introduce a helper function to replace the common code to initialize VFIODevice in pci, platform, ap and ccw VFIO device. No functional change intended. Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/ccw: Move VFIODevice initializations in vfio_ccw_instance_initZhenzhong Duan1-15/+15
Some of the VFIODevice initializations is in vfio_ccw_realize, move all of them in vfio_ccw_instance_init. No functional change intended. Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Eric Farman <farman@linux.ibm.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/ap: Move VFIODevice initializations in vfio_ap_instance_initZhenzhong Duan1-13/+13
Some of the VFIODevice initializations is in vfio_ap_realize, move all of them in vfio_ap_instance_init. No functional change intended. Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Eric Farman <farman@linux.ibm.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/platform: Move VFIODevice initializations in vfio_platform_instance_initZhenzhong Duan1-5/+5
Some of the VFIODevice initializations is in vfio_platform_realize, move all of them in vfio_platform_instance_init. No functional change intended. Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/pci: Move VFIODevice initializations in vfio_instance_initZhenzhong Duan1-4/+6
Some of the VFIODevice initializations is in vfio_realize, move all of them in vfio_instance_init. No functional change intended. Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19hw/i386: Activate IOMMUFD for q35 machinesCédric Le Goater1-0/+1
Signed-off-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19kconfig: Activate IOMMUFD for s390x machinesCédric Le Goater1-0/+1
Signed-off-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19hw/arm: Activate IOMMUFD for virt machinesCédric Le Goater1-0/+1
Signed-off-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio: Make VFIOContainerBase poiner parameter const in VFIOIOMMUOps callbacksZhenzhong Duan4-25/+28
Some of the callbacks in VFIOIOMMUOps pass VFIOContainerBase poiner, those callbacks only need read access to the sub object of VFIOContainerBase. So make VFIOContainerBase, VFIOContainer and VFIOIOMMUFDContainer as const in these callbacks. Local functions called by those callbacks also need same changes to avoid build error. Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/ccw: Make vfio cdev pre-openable by passing a file handleZhenzhong Duan1-3/+22
This gives management tools like libvirt a chance to open the vfio cdev with privilege and pass FD to qemu. This way qemu never needs to have privilege to open a VFIO or iommu cdev node. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/ccw: Allow the selection of a given iommu backendZhenzhong Duan1-0/+6
Now we support two types of iommu backends, let's add the capability to select one of them. This depends on whether an iommufd object has been linked with the vfio-ccw device: If the user wants to use the legacy backend, it shall not link the vfio-ccw device with any iommufd object: -device vfio-ccw,sysfsdev=/sys/bus/mdev/devices/XXX This is called the legacy mode/backend. If the user wants to use the iommufd backend (/dev/iommu) it shall pass an iommufd object id in the vfio-ccw device options: -object iommufd,id=iommufd0 -device vfio-ccw,sysfsdev=/sys/bus/mdev/devices/XXX,iommufd=iommufd0 Suggested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/ap: Make vfio cdev pre-openable by passing a file handleZhenzhong Duan1-1/+22
This gives management tools like libvirt a chance to open the vfio cdev with privilege and pass FD to qemu. This way qemu never needs to have privilege to open a VFIO or iommu cdev node. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/ap: Allow the selection of a given iommu backendZhenzhong Duan1-0/+6
Now we support two types of iommu backends, let's add the capability to select one of them. This depends on whether an iommufd object has been linked with the vfio-ap device: if the user wants to use the legacy backend, it shall not link the vfio-ap device with any iommufd object: -device vfio-ap,sysfsdev=/sys/bus/mdev/devices/XXX This is called the legacy mode/backend. If the user wants to use the iommufd backend (/dev/iommu) it shall pass an iommufd object id in the vfio-ap device options: -object iommufd,id=iommufd0 -device vfio-ap,sysfsdev=/sys/bus/mdev/devices/XXX,iommufd=iommufd0 Suggested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/platform: Make vfio cdev pre-openable by passing a file handleZhenzhong Duan1-8/+24
This gives management tools like libvirt a chance to open the vfio cdev with privilege and pass FD to qemu. This way qemu never needs to have privilege to open a VFIO or iommu cdev node. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/platform: Allow the selection of a given iommu backendZhenzhong Duan1-0/+6
Now we support two types of iommu backends, let's add the capability to select one of them. This depends on whether an iommufd object has been linked with the vfio-platform device: If the user wants to use the legacy backend, it shall not link the vfio-platform device with any iommufd object: -device vfio-platform,host=XXX This is called the legacy mode/backend. If the user wants to use the iommufd backend (/dev/iommu) it shall pass an iommufd object id in the vfio-platform device options: -object iommufd,id=iommufd0 -device vfio-platform,host=XXX,iommufd=iommufd0 Suggested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/pci: Make vfio cdev pre-openable by passing a file handleZhenzhong Duan3-16/+67
This gives management tools like libvirt a chance to open the vfio cdev with privilege and pass FD to qemu. This way qemu never needs to have privilege to open a VFIO or iommu cdev node. Together with the earlier support of pre-opening /dev/iommu device, now we have full support of passing a vfio device to unprivileged qemu by management tool. This mode is no more considered for the legacy backend. So let's remove the "TODO" comment. Add helper functions vfio_device_set_fd() and vfio_device_get_name() to set fd and get device name, they will also be used by other vfio devices. There is no easy way to check if a device is mdev with FD passing, so fail the x-balloon-allowed check unconditionally in this case. There is also no easy way to get BDF as name with FD passing, so we fake a name by VFIO_FD[fd]. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/pci: Allow the selection of a given iommu backendEric Auger1-0/+6
Now we support two types of iommu backends, let's add the capability to select one of them. This depends on whether an iommufd object has been linked with the vfio-pci device: If the user wants to use the legacy backend, it shall not link the vfio-pci device with any iommufd object: -device vfio-pci,host=0000:02:00.0 This is called the legacy mode/backend. If the user wants to use the iommufd backend (/dev/iommu) it shall pass an iommufd object id in the vfio-pci device options: -object iommufd,id=iommufd0 -device vfio-pci,host=0000:02:00.0,iommufd=iommufd0 Suggested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/iommufd: Enable pci hot reset through iommufd cdev interfaceZhenzhong Duan2-0/+151
Implement the newly introduced pci_hot_reset callback named iommufd_cdev_pci_hot_reset to do iommufd specific check and reset operation. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/pci: Introduce a vfio pci hot reset interfaceZhenzhong Duan3-162/+179
Legacy vfio pci and iommufd cdev have different process to hot reset vfio device, expand current code to abstract out pci_hot_reset callback for legacy vfio, this same interface will also be used by iommufd cdev vfio device. Rename vfio_pci_hot_reset to vfio_legacy_pci_hot_reset and move it into container.c. vfio_pci_[pre/post]_reset and vfio_pci_host_match are exported so they could be called in legacy and iommufd pci_hot_reset callback. Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/pci: Extract out a helper vfio_pci_get_pci_hot_reset_infoZhenzhong Duan2-17/+40
This helper will be used by both legacy and iommufd backends. No functional changes intended. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/iommufd: Add support for iova_ranges and pgsizesZhenzhong Duan1-1/+55
Some vIOMMU such as virtio-iommu use IOVA ranges from host side to setup reserved ranges for passthrough device, so that guest will not use an IOVA range beyond host support. Use an uAPI of IOMMUFD to get IOVA ranges of host side and pass to vIOMMU just like the legacy backend, if this fails, fallback to 64bit IOVA range. Also use out_iova_alignment returned from uAPI as pgsizes instead of qemu_real_host_page_size() as a fallback. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-12-19vfio/iommufd: Relax assert check for iommufd backendZhenzhong Duan2-4/+4
Currently iommufd doesn't support dirty page sync yet, but it will not block us doing live migration if VFIO migration is force enabled. So in this case we allow set_dirty_page_tracking to be NULL. Note we don't need same change for query_dirty_bitmap because when dirty page sync isn't supported, query_dirty_bitmap will never be called. Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
generated by cgit v1.1 at 2025-02-15 18:35:46 +0000