aboutsummaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2021-10-12aspeed/smc: Add default reset valuesCédric Le Goater
This simplifies the reset handler and has the benefit to remove some "bad" use of the segments array as an identifier of the controller model. Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-10-12aspeed/smc: QOMify AspeedSMCFlashCédric Le Goater
AspeedSMCFlash is a small structure representing the AHB memory window through which the contents of a flash device can be accessed with MMIOs. Introduce an AspeedSMCFlash SysBusDevice model and attach the associated memory region to the newly instantiated objects. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-10-12aspeed/smc: Rename AspeedSMCFlash 'id' to 'cs'Cédric Le Goater
'cs' is a more appropriate name to index SPI flash devices. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-10-12aspeed/smc: Remove the 'size' attribute from AspeedSMCFlashCédric Le Goater
AspeedSMCFlash::size is only used to compute the initial size of the boot_rom region. Not very useful, so directly call memory_region_size() instead. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-10-12aspeed/smc: Remove the 'flash' attribute from AspeedSMCFlashCédric Le Goater
There is no need to keep a reference of the flash qdev in the AspeedSMCFlash state: the SPI bus takes ownership and will release its resources. Remove AspeedSMCFlash::flash. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-10-12aspeed/smc: Drop AspeedSMCController structureCédric Le Goater
The characteristics of the Aspeed controllers are described in a AspeedSMCController structure which is redundant with the AspeedSMCClass. Move all attributes under the class and adapt the code to use class attributes instead. This is a large change but it is functionally equivalent. Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-10-08macfb: add vertical blank interruptMark Cave-Ayland
The MacOS driver expects a 60.15Hz vertical blank interrupt to be generated by the framebuffer which in turn schedules the mouse driver via the Vertical Retrace Manager. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211007221253.29024-13-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-08macfb: add common monitor modes supported by the MacOS toolbox ROMMark Cave-Ayland
The monitor modes table is found by experimenting with the Monitors Control Panel in MacOS and analysing the reads/writes. From this it can be found that the mode is controlled by writes to the DAFB_MODE_CTRL1 and DAFB_MODE_CTRL2 registers. Implement the first block of DAFB registers as a register array including the existing sense register, the newly discovered control registers above, and also the DAFB_MODE_VADDR1 and DAFB_MODE_VADDR2 registers which are used by NetBSD to determine the current video mode. These experiments also show that the offset of the start of video RAM and the stride can change depending upon the monitor mode, so update macfb_draw_graphic() and both the BI_MAC_VADDR and BI_MAC_VROW bootinfo for the q800 machine accordingly. Finally update macfb_common_realize() so that only the resolution and depth supported by the display type can be specified on the command line, and add an error hint showing the list of supported resolutions and depths if the user tries to specify an invalid display mode. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211007221253.29024-10-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-08macfb: add qdev property to specify display typeMark Cave-Ayland
Since the available resolutions and colour depths are determined by the attached display type, add a qdev property to allow the display type to be specified. The main resolutions of interest are high resolution 1152x870 with 8-bit colour and SVGA resolution up to 800x600 with 24-bit colour so update the q800 machine to allow high resolution mode if specified and otherwise fall back to SVGA. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211007221253.29024-9-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-08macfb: implement mode sense to allow display type to be detectedMark Cave-Ayland
The MacOS toolbox ROM uses the monitor sense to detect the display type and then offer a fixed set of resolutions and colour depths accordingly. Implement the monitor sense using information found in Apple Technical Note HW26: "Macintosh Quadra Built-In Video" along with some local experiments. Since the default configuration is 640 x 480 with 8-bit colour then hardcode the sense register to return MACFB_DISPLAY_VGA for now. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211007221253.29024-8-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-07Merge remote-tracking branch ↵Richard Henderson
'remotes/vsementsov/tags/pull-jobs-2021-10-07-v2' into staging mirror: Handle errors after READY cancel v2: add small fix by Stefano, Hanna's series fixed # gpg: Signature made Thu 07 Oct 2021 08:25:07 AM PDT # gpg: using RSA key 8B9C26CDB2FD147C880E86A1561F24C1F19F79FB # gpg: Good signature from "Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 8B9C 26CD B2FD 147C 880E 86A1 561F 24C1 F19F 79FB * remotes/vsementsov/tags/pull-jobs-2021-10-07-v2: iotests: Add mirror-ready-cancel-error test mirror: Do not clear .cancelled mirror: Stop active mirroring after force-cancel mirror: Check job_is_cancelled() earlier mirror: Use job_is_cancelled() job: Add job_cancel_requested() job: Do not soft-cancel after a job is done jobs: Give Job.force_cancel more meaning job: @force parameter for job_cancel_sync() job: Force-cancel jobs in a failed transaction mirror: Drop s->synced mirror: Keep s->synced on error job: Context changes in job_completed_txn_abort() block/aio_task: assert `max_busy_tasks` is greater than 0 block/backup: avoid integer overflow of `max-workers` Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-07job: Add job_cancel_requested()Hanna Reitz
Most callers of job_is_cancelled() actually want to know whether the job is on its way to immediate termination. For example, we refuse to pause jobs that are cancelled; but this only makes sense for jobs that are really actually cancelled. A mirror job that is cancelled during READY with force=false should absolutely be allowed to pause. This "cancellation" (which is actually a kind of completion) may take an indefinite amount of time, and so should behave like any job during normal operation. For example, with on-target-error=stop, the job should stop on write errors. (In contrast, force-cancelled jobs should not get write errors, as they should just terminate and not do further I/O.) Therefore, redefine job_is_cancelled() to only return true for jobs that are force-cancelled (which as of HEAD^ means any job that interprets the cancellation request as a request for immediate termination), and add job_cancel_requested() as the general variant, which returns true for any jobs which have been requested to be cancelled, whether it be immediately or after an arbitrarily long completion phase. Finally, here is a justification for how different job_is_cancelled() invocations are treated by this patch: - block/mirror.c (mirror_run()): - The first invocation is a while loop that should loop until the job has been cancelled or scheduled for completion. What kind of cancel does not matter, only the fact that the job is supposed to end. - The second invocation wants to know whether the job has been soft-cancelled. Calling job_cancel_requested() is a bit too broad, but if the job were force-cancelled, we should leave the main loop as soon as possible anyway, so this should not matter here. - The last two invocations already check force_cancel, so they should continue to use job_is_cancelled(). - block/backup.c, block/commit.c, block/stream.c, anything in tests/: These jobs know only force-cancel, so there is no difference between job_is_cancelled() and job_cancel_requested(). We can continue using job_is_cancelled(). - job.c: - job_pause_point(), job_yield(), job_sleep_ns(): Only force-cancelled jobs should be prevented from being paused. Continue using job_is_cancelled(). - job_update_rc(), job_finalize_single(), job_finish_sync(): These functions are all called after the job has left its main loop. The mirror job (the only job that can be soft-cancelled) will clear .cancelled before leaving the main loop if it has been soft-cancelled. Therefore, these functions will observe .cancelled to be true only if the job has been force-cancelled. We can continue to use job_is_cancelled(). (Furthermore, conceptually, a soft-cancelled mirror job should not report to have been cancelled. It should report completion (see also the block-job-cancel QAPI documentation). Therefore, it makes sense for these functions not to distinguish between a soft-cancelled mirror job and a job that has completed as normal.) - job_completed_txn_abort(): All jobs other than @job have been force-cancelled. job_is_cancelled() must be true for them. Regarding @job itself: job_completed_txn_abort() is mostly called when the job's return value is not 0. A soft-cancelled mirror has a return value of 0, and so will not end up here then. However, job_cancel() invokes job_completed_txn_abort() if the job has been deferred to the main loop, which is mostly the case for completed jobs (which skip the assertion), but not for sure. To be safe, use job_cancel_requested() in this assertion. - job_complete(): This is function eventually invoked by the user (through qmp_block_job_complete() or qmp_job_complete(), or job_complete_sync(), which comes from qemu-img). The intention here is to prevent a user from invoking job-complete after the job has been cancelled. This should also apply to soft cancelling: After a mirror job has been soft-cancelled, the user should not be able to decide otherwise and have it complete as normal (i.e. pivoting to the target). - job_cancel(): Both functions are equivalent (see comment there), but we want to use job_is_cancelled(), because this shows that we call job_completed_txn_abort() only for force-cancelled jobs. (As explained for job_update_rc(), soft-cancelled jobs should be treated as if they have completed as normal.) Buglink: https://gitlab.com/qemu-project/qemu/-/issues/462 Signed-off-by: Hanna Reitz <hreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20211006151940.214590-9-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07jobs: Give Job.force_cancel more meaningHanna Reitz
We largely have two cancel modes for jobs: First, there is actual cancelling. The job is terminated as soon as possible, without trying to reach a consistent result. Second, we have mirror in the READY state. Technically, the job is not really cancelled, but it just is a different completion mode. The job can still run for an indefinite amount of time while it tries to reach a consistent result. We want to be able to clearly distinguish which cancel mode a job is in (when it has been cancelled). We can use Job.force_cancel for this, but right now it only reflects cancel requests from the user with force=true, but clearly, jobs that do not even distinguish between force=false and force=true are effectively always force-cancelled. So this patch has Job.force_cancel signify whether the job will terminate as soon as possible (force_cancel=true) or whether it will effectively remain running despite being "cancelled" (force_cancel=false). To this end, we let jobs that provide JobDriver.cancel() tell the generic job code whether they will terminate as soon as possible or not, and for jobs that do not provide that method we assume they will. Signed-off-by: Hanna Reitz <hreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20211006151940.214590-7-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07job: @force parameter for job_cancel_sync()Hanna Reitz
Callers should be able to specify whether they want job_cancel_sync() to force-cancel the job or not. In fact, almost all invocations do not care about consistency of the result and just want the job to terminate as soon as possible, so they should pass force=true. The replication block driver is the exception, specifically the active commit job it runs. As for job_cancel_sync_all(), all callers want it to force-cancel all jobs, because that is the point of it: To cancel all remaining jobs as quickly as possible (generally on process termination). So make it invoke job_cancel_sync() with force=true. This changes some iotest outputs, because quitting qemu while a mirror job is active will now lead to it being cancelled instead of completed, which is what we want. (Cancelling a READY mirror job with force=false may take an indefinite amount of time, which we do not want when quitting. If users want consistent results, they must have all jobs be done before they quit qemu.) Buglink: https://gitlab.com/qemu-project/qemu/-/issues/462 Signed-off-by: Hanna Reitz <hreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20211006151940.214590-6-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07hw/char/mchp_pfsoc_mmuart: QOM'ify PolarFire MMUARTPhilippe Mathieu-Daudé
- Embed SerialMM in MchpPfSoCMMUartState and QOM-initialize it - Alias SERIAL_MM 'chardev' property on MCHP_PFSOC_UART - Forward SerialMM sysbus IRQ in mchp_pfsoc_mmuart_realize() - Add DeviceReset() method - Add vmstate structure for migration - Register device in 'input' category - Keep mchp_pfsoc_mmuart_create() behavior Note, serial_mm_init() calls qdev_set_legacy_instance_id(). This call is only needed for backwards-compatibility of incoming migration data with old versions of QEMU which implemented migration of devices with hand-rolled code. Since this device didn't previously handle migration at all, then it doesn't need to set the legacy instance ID. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210925133407.1259392-4-f4bug@amsat.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-07hw/char/mchp_pfsoc_mmuart: Use a MemoryRegion containerPhilippe Mathieu-Daudé
Our device have 2 different I/O regions: - a 16550 UART mapped for 32-bit accesses - 13 extra registers Instead of mapping each region on the main bus, introduce a container, map the 2 devices regions on the container, and map the container on the main bus. Before: (qemu) info mtree ... 0000000020100000-000000002010001f (prio 0, i/o): serial 0000000020100020-000000002010101f (prio 0, i/o): mchp.pfsoc.mmuart 0000000020102000-000000002010201f (prio 0, i/o): serial 0000000020102020-000000002010301f (prio 0, i/o): mchp.pfsoc.mmuart 0000000020104000-000000002010401f (prio 0, i/o): serial 0000000020104020-000000002010501f (prio 0, i/o): mchp.pfsoc.mmuart 0000000020106000-000000002010601f (prio 0, i/o): serial 0000000020106020-000000002010701f (prio 0, i/o): mchp.pfsoc.mmuart After: (qemu) info mtree ... 0000000020100000-0000000020100fff (prio 0, i/o): mchp.pfsoc.mmuart 0000000020100000-000000002010001f (prio 0, i/o): serial 0000000020100020-0000000020100fff (prio 0, i/o): mchp.pfsoc.mmuart.regs 0000000020102000-0000000020102fff (prio 0, i/o): mchp.pfsoc.mmuart 0000000020102000-000000002010201f (prio 0, i/o): serial 0000000020102020-0000000020102fff (prio 0, i/o): mchp.pfsoc.mmuart.regs 0000000020104000-0000000020104fff (prio 0, i/o): mchp.pfsoc.mmuart 0000000020104000-000000002010401f (prio 0, i/o): serial 0000000020104020-0000000020104fff (prio 0, i/o): mchp.pfsoc.mmuart.regs 0000000020106000-0000000020106fff (prio 0, i/o): mchp.pfsoc.mmuart 0000000020106000-000000002010601f (prio 0, i/o): serial 0000000020106020-0000000020106fff (prio 0, i/o): mchp.pfsoc.mmuart.regs Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Bin Meng <bin.meng@windriver.com> Message-id: 20210925133407.1259392-3-f4bug@amsat.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-07hw/char/mchp_pfsoc_mmuart: Simplify MCHP_PFSOC_MMUART_REG definitionPhilippe Mathieu-Daudé
The current MCHP_PFSOC_MMUART_REG_SIZE definition represent the size occupied by all the registers. However all registers are 32-bit wide, and the MemoryRegionOps handlers are restricted to 32-bit: static const MemoryRegionOps mchp_pfsoc_mmuart_ops = { .read = mchp_pfsoc_mmuart_read, .write = mchp_pfsoc_mmuart_write, .impl = { .min_access_size = 4, .max_access_size = 4, }, Avoid being triskaidekaphobic, simplify by using the number of registers. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210925133407.1259392-2-f4bug@amsat.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-06Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20211006' into stagingRichard Henderson
More fixes for fedora-i386-cross Add dup_const_tl Expand MemOp MO_SIZE Move MemOpIdx out of tcg.h Vector support for tcg/s390x # gpg: Signature made Wed 06 Oct 2021 08:12:53 AM PDT # gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F # gpg: issuer "richard.henderson@linaro.org" # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [ultimate] * remotes/rth/tags/pull-tcg-20211006: (28 commits) tcg/s390x: Implement TCG_TARGET_HAS_cmpsel_vec tcg/s390x: Implement TCG_TARGET_HAS_bitsel_vec tcg/s390x: Implement TCG_TARGET_HAS_sat_vec tcg/s390x: Implement TCG_TARGET_HAS_minmax_vec tcg/s390x: Implement vector shift operations tcg/s390x: Implement TCG_TARGET_HAS_mul_vec tcg/s390x: Implement andc, orc, abs, neg, not vector operations tcg/s390x: Implement minimal vector operations tcg/s390x: Implement tcg_out_dup*_vec tcg/s390x: Implement tcg_out_mov for vector types tcg/s390x: Implement tcg_out_ld/st for vector types tcg/s390x: Add host vector framework tcg/s390x: Merge TCG_AREG0 and TCG_REG_CALL_STACK into TCGReg tcg/s390x: Change FACILITY representation tcg/s390x: Rename from tcg/s390 tcg: Expand usadd/ussub with umin/umax hw/core/cpu: Re-sort the non-pointers to the end of CPUClass trace: Split guest_mem_before plugins: Reorg arguments to qemu_plugin_vcpu_mem_cb accel/tcg: Pass MemOpIdx to atomic_trace_*_post ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-06block: introduce max_hw_iov for use in scsi-genericPaolo Bonzini
Linux limits the size of iovecs to 1024 (UIO_MAXIOV in the kernel sources, IOV_MAX in POSIX). Because of this, on some host adapters requests with many iovecs are rejected with -EINVAL by the io_submit() or readv()/writev() system calls. In fact, the same limit applies to SG_IO as well. To fix both the EINVAL and the possible performance issues from using fewer iovecs than allowed by Linux (some HBAs have max_segments as low as 128), introduce a separate entry in BlockLimits to hold the max_segments value from sysfs. This new limit is used only for SG_IO and clamped to bs->bl.max_iov anyway, just like max_hw_transfer is clamped to bs->bl.max_transfer. Reported-by: Halil Pasic <pasic@linux.ibm.com> Cc: Hanna Reitz <hreitz@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: qemu-block@nongnu.org Cc: qemu-stable@nongnu.org Fixes: 18473467d5 ("file-posix: try BLKSECTGET on block devices too, do not round to power of 2", 2021-06-25) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210923130436.1187591-1-pbonzini@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-10-06block: implement bdrv_new_open_driver_opts()Vladimir Sementsov-Ogievskiy
Add version of bdrv_new_open_driver() that supports QDict options. We'll use it in further commit. Simply add one more argument to bdrv_new_open_driver() is worse, as there are too many invocations of bdrv_new_open_driver() to update then. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Suggested-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20210920115538.264372-2-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-10-06include/block.h: remove outdated commentEmanuele Giuseppe Esposito
There are a couple of errors in bdrv_drained_begin header comment: - block_job_pause does not exist anymore, it has been replaced with job_pause in b15de82867 - job_pause is automatically invoked as a .drained_begin callback (child_job_drained_begin) by the child_job BdrvChildClass struct in blockjob.c. So no additional pause should be required. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Message-Id: <20210903113800.59970-1-eesposit@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-10-05hw/core/cpu: Re-sort the non-pointers to the end of CPUClassRichard Henderson
Despite the comment, the members were not kept at the end. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-05plugins: Reorg arguments to qemu_plugin_vcpu_mem_cbRichard Henderson
Use the MemOpIdx directly, rather than the rearrangement of the same bits currently done by the trace infrastructure. Pass in enum qemu_plugin_mem_rw so that we are able to treat read-modify-write operations as a single operation. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-05tcg: Split out MemOpIdx to exec/memopidx.hRichard Henderson
Move this code from tcg/tcg.h to its own header. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-05tcg: Rename TCGMemOpIdx to MemOpIdxRichard Henderson
We're about to move this out of tcg.h, so rename it as we did when moving MemOp. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-05tcg: Expand MO_SIZE to 3 bitsRichard Henderson
We have lacked expressive support for memory sizes larger than 64-bits for a while. Fixing that requires adjustment to several points where we used this for array indexing, and two places that develop -Wswitch warnings after the change. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-05tcg: add dup_const_tl wrapperPhilipp Tomsich
dup_const always generates a uint64_t, which may exceed the size of a target_long (generating warnings with recent-enough compilers). To ensure that we can use dup_const both for 64bit and 32bit targets, this adds dup_const_tl, which either maps back to dup_const (for 64bit targets) or provides a similar implementation using 32bit constants. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Message-Id: <20211003214243.3813425-1-philipp.tomsich@vrull.eu> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-05hw/i386/acpi: fix conflicting IO address range for acpi pci hotplug in q35Ani Sinha
Change caf108bc58790 ("hw/i386/acpi-build: Add ACPI PCI hot-plug methods to Q35") selects an IO address range for acpi based PCI hotplug for q35 arbitrarily. It starts at address 0x0cc4 and ends at 0x0cdb. At the time when the patch was written but the final version of the patch was not yet pushed upstream, this address range was free and did not conflict with any other IO address ranges. However, with the following change, this address range was no longer conflict free as in this change, the IO address range (value of ACPI_PCIHP_SIZE) was incremented by four bytes: b32bd763a1ca92 ("pci: introduce acpi-index property for PCI device") This can be seen from the output of QMP command 'info mtree' : 0000000000000600-0000000000000603 (prio 0, i/o): acpi-evt 0000000000000604-0000000000000605 (prio 0, i/o): acpi-cnt 0000000000000608-000000000000060b (prio 0, i/o): acpi-tmr 0000000000000620-000000000000062f (prio 0, i/o): acpi-gpe0 0000000000000630-0000000000000637 (prio 0, i/o): acpi-smi 0000000000000cc4-0000000000000cdb (prio 0, i/o): acpi-pci-hotplug 0000000000000cd8-0000000000000ce3 (prio 0, i/o): acpi-cpu-hotplug It shows that there is a region of conflict between IO regions of acpi pci hotplug and acpi cpu hotplug. Unfortunately, the change caf108bc58790 did not update the IO address range appropriately before it was pushed upstream to accommodate the increased length of the IO address space introduced in change b32bd763a1ca92. Due to this bug, windows guests complain 'This device cannot find enough free resources it can use' in the device manager panel for extended IO buses. This issue also breaks the correct functioning of pci hotplug as the following shows that the IO space for pci hotplug has been truncated: (qemu) info mtree -f FlatView #0 AS "I/O", root: io Root memory region: io 0000000000000cc4-0000000000000cd7 (prio 0, i/o): acpi-pci-hotplug 0000000000000cd8-0000000000000cf7 (prio 0, i/o): acpi-cpu-hotplug Therefore, in this fix, we adjust the IO address range for the acpi pci hotplug so that it does not conflict with cpu hotplug and there is no truncation of IO spaces. The starting IO address of PCI hotplug region has been decremented by four bytes in order to accommodate four byte increment in the IO address space introduced by change b32bd763a1ca92 ("pci: introduce acpi-index property for PCI device") After fixing, the following are the corrected IO ranges: 0000000000000600-0000000000000603 (prio 0, i/o): acpi-evt 0000000000000604-0000000000000605 (prio 0, i/o): acpi-cnt 0000000000000608-000000000000060b (prio 0, i/o): acpi-tmr 0000000000000620-000000000000062f (prio 0, i/o): acpi-gpe0 0000000000000630-0000000000000637 (prio 0, i/o): acpi-smi 0000000000000cc0-0000000000000cd7 (prio 0, i/o): acpi-pci-hotplug 0000000000000cd8-0000000000000ce3 (prio 0, i/o): acpi-cpu-hotplug This change has been tested using a Windows Server 2019 guest VM. Windows no longer complains after this change. Fixes: caf108bc58790 ("hw/i386/acpi-build: Add ACPI PCI hot-plug methods to Q35") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/561 Signed-off-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Julia Suvorova <jusual@redhat.com> Message-Id: <20210916132838.3469580-3-ani@anisinha.ca> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: AcpiGenericAddress no longer used to map/access fields of MMIO, drop ↵Igor Mammedov
packed attribute Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-36-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: remove no longer used build_header()Igor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-35-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: build_facs: use build_append_int_noprefix() API to compose tableIgor Mammedov
Drop usage of packed structures and explicit endian conversions when building table and use endian agnostic build_append_int_noprefix() API to build it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-34-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: arm/virt: build_gtdt: use acpi_table_begin()/acpi_table_end() instead ↵Igor Mammedov
of build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. while at it, replace packed structure with endian agnostic build_append_FOO() API. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-33-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: arm/virt: build_spcr: use acpi_table_begin()/acpi_table_end() instead ↵Igor Mammedov
of build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. while at it, replace packed structure with endian agnostic build_append_FOO() API. PS: Spec is Microsoft hosted, however 1.02 is no where to be found (MS lists only the current revision) and the current revision is 1.07, so bring comments in line with 1.07 as this is the only available spec. There is no content change between originally implemented 1.02 (using QEMU code as reference) and 1.07. The only change is renaming 'Reserved2' field to 'Language', with the same 0 value. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-32-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: arm/virt: convert build_iort() to endian agnostic build_append_FOO() APIIgor Mammedov
Drop usage of packed structures and explicit endian conversions when building IORT table use endian agnostic build_append_int_noprefix() API to build it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20210924122802.1455362-30-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com>
2021-10-05acpi: arm: virt: build_iort: use acpi_table_begin()/acpi_table_end() instead ↵Igor Mammedov
of build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-29-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: arm/virt: madt: use build_append_int_noprefix() API to compose MADT tableIgor Mammedov
Drop usage of packed structures and explicit endian conversions when building MADT table for arm/x86 and use endian agnostic build_append_int_noprefix() API to build it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-26-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: x86: madt: use build_append_int_noprefix() API to compose MADT tableIgor Mammedov
Drop usage of packed structures and explicit endian conversions when building MADT table for arm/x86 and use endian agnostic build_append_int_noprefix() API to build it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-25-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: x86: set enabled when composing _MAT entriesIgor Mammedov
Instead of composing disabled _MAT entry and then later on patching it to enabled for hotpluggbale CPUs in DSDT, set it to enabled at the time _MAT entry is built. It will allow to drop usage of packed structures in following patches when build_madt() is switched to use build_append_int_noprefix() API. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-24-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: x86: remove dead codeIgor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-23-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: madt: arm/x86: use acpi_table_begin()/acpi_table_end() instead of ↵Igor Mammedov
build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-22-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: build_dmar_q35: use acpi_table_begin()/acpi_table_end() instead of ↵Igor Mammedov
build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. While at it switch to build_append_int_noprefix() to build table entries tables. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-19-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: use build_append_int_noprefix() API to compose SRAT tableIgor Mammedov
Drop usage of packed structures and explicit endian conversions when building SRAT tables for arm/x86 and use endian agnostic build_append_int_noprefix() API to build it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-18-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: arm/x86: build_srat: use acpi_table_begin()/acpi_table_end() instead ↵Igor Mammedov
of build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. While at it switch to build_append_int_noprefix() to build table entries (which also removes some manual offset calculations) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-17-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: build_tpm_tcpa: use acpi_table_begin()/acpi_table_end() instead of ↵Igor Mammedov
build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. While at it switch to build_append_int_noprefix() to build table entries (which also removes some manual offset calculations). Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-16-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: build_hpet: use acpi_table_begin()/acpi_table_end() instead of ↵Igor Mammedov
build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. while at it convert build_hpet() to endian agnostic build_append_FOO() API Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20210924122802.1455362-15-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: build_xsdt: use acpi_table_begin()/acpi_table_end() instead of ↵Igor Mammedov
build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. While at it switch to build_append_int_noprefix() to build entries to other tables (which also removes some manual offset calculations). Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-4-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: build_rsdt: use acpi_table_begin()/acpi_table_end() instead of ↵Igor Mammedov
build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offests magic from API user. While at it switch to build_append_int_noprefix() to build entries to other tables (which also removes some manual offset calculations). Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: add helper routines to initialize ACPI tablesIgor Mammedov
Patch introduces acpi_table_begin()/ acpi_table_end() API that hides pointer/offset arithmetic from user as opposed to build_header(), to prevent errors caused by it [1]. acpi_table_begin(): initializes table header and keeps track of table data/offsets acpi_table_end(): sets actual table length and tells bios loader where table is for the later initialization on guest side. 1) commits bb9feea43179 x86: acpi: use offset instead of pointer when using build_header() 4d027afeb3a9 Virt: ACPI: fix qemu assert due to re-assigned table data address Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Yanan Wang <wangyanan55@huawei.com>
2021-10-05vhost-vsock: handle common features in vhost-vsock-commonStefano Garzarella
virtio-vsock features, like VIRTIO_VSOCK_F_SEQPACKET, can be handled by vhost-vsock-common parent class. In this way, we can reuse the same code for all virtio-vsock backends (i.e. vhost-vsock, vhost-user-vsock). Let's move `seqpacket` property to vhost-vsock-common class, add vhost_vsock_common_get_features() used by children, and disable `seqpacket` for vhost-user-vsock device for machine types < 6.2. The behavior of vhost-vsock device doesn't change; vhost-user-vsock device now supports `seqpacket` property. Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20210921161642.206461-3-sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05vhost-vsock: fix migration issue when seqpacket is supportedStefano Garzarella
Commit 1e08fd0a46 ("vhost-vsock: SOCK_SEQPACKET feature bit support") enabled the SEQPACKET feature bit. This commit is released with QEMU 6.1, so if we try to migrate a VM where the host kernel supports SEQPACKET but machine type version is less than 6.1, we get the following errors: Features 0x130000002 unsupported. Allowed features: 0x179000000 Failed to load virtio-vhost_vsock:virtio error while loading state for instance 0x0 of device '0000:00:05.0/virtio-vhost_vsock' load of migration failed: Operation not permitted Let's disable the feature bit for machine types < 6.1. We add a new OnOffAuto property for this, called `seqpacket`. When it is `auto` (default), QEMU behaves as before, trying to enable the feature, when it is `on` QEMU will fail if the backend (vhost-vsock kernel module) doesn't support it. Fixes: 1e08fd0a46 ("vhost-vsock: SOCK_SEQPACKET feature bit support") Cc: qemu-stable@nongnu.org Reported-by: Jiang Wang <jiang.wang@bytedance.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20210921161642.206461-2-sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>