aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-10-12tests/docker: promote debian-riscv64-cross to a full imageAlex Bennée3-8/+43
To be able to cross build QEMU itself we need to include a few more libraries. These are only available in Debian's unstable ports repo for now so we need to base the riscv64 image on sid with the the minimal libs needed to build QEMU (glib/pixman). The result works but is not as clean as using build-dep to bring in more dependencies. However sid is by definition a shifting pile of sand and by keeping the list of libs minimal we reduce the chance of having an image we can't build. It's good enough for a basic cross build testing of TCG. Cc: "Daniel P. Berrangé" <berrange@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210914185830.1378771-2-richard.henderson@linaro.org> [AJB: tweak allow_failure] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210917162332.3511179-5-alex.bennee@linaro.org>
2021-10-12tests/tcg: move some multiarch files and make conditionalAlex Bennée4-6/+15
We had some messy code to filter out stuff we can't build. Lets junk that and simplify the logic by pushing some stuff into subdirs. In particular we move: float_helpers into libs - not a standalone test linux-test into linux - so we only build on Linux hosts This allows for at least some of the tests to be nominally usable by *BSD user builds. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Cc: Warner Losh <imp@bsdimp.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Warner Losh <imp@bsdimp.com> Message-Id: <20210917162332.3511179-4-alex.bennee@linaro.org>
2021-10-12tests/tcg/sha1: remove endian includeAlex Bennée1-1/+0
This doesn't exist in BSD world and doesn't seem to be needed by either. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Warner Losh <imp@bsdimp.com> Message-Id: <20210917162332.3511179-3-alex.bennee@linaro.org>
2021-10-12configure: don't override the selected host test compiler if definedAlex Bennée1-2/+4
There are not many cases you would want to do this but one is if you want to use a test friendly compiler like gcc instead of a system compiler like clang. Either way we should honour the users choice if they have made it. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Cc: Warner Losh <imp@bsdimp.com> Reviewed-by: Warner Losh <imp@bsdimp.com> Message-Id: <20210917162332.3511179-2-alex.bennee@linaro.org>
2021-10-11Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into ↵Richard Henderson1-13/+15
staging Pull request # gpg: Signature made Mon 11 Oct 2021 05:40:35 AM PDT # gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full] # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" [full] * remotes/stefanha/tags/block-pull-request: iothread: use IOThreadParamInfo in iothread_[set|get]_param() iothread: rename PollParamInfo to IOThreadParamInfo Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-08Merge remote-tracking branch ↵Richard Henderson4-30/+429
'remotes/vivier-m68k/tags/m68k-next-pull-request' into staging Pull request q800 20211008 macfb: fixes for booting MacOS # gpg: Signature made Fri 08 Oct 2021 04:44:44 AM PDT # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] * remotes/vivier-m68k/tags/m68k-next-pull-request: q800: wire macfb IRQ to separate video interrupt on VIA2 macfb: add vertical blank interrupt macfb: fix 24-bit RGB pixel encoding macfb: fix up 1-bit pixel encoding macfb: add common monitor modes supported by the MacOS toolbox ROM macfb: add qdev property to specify display type macfb: implement mode sense to allow display type to be detected macfb: add trace events for reading and writing the control registers macfb: use memory_region_init_ram() in macfb_common_realize() for the framebuffer macfb: fix overflow of color_palette array macfb: fix invalid object reference in macfb_common_realize() macfb: update macfb.c to use the Error API best practices macfb: handle errors that occur during realize Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-08q800: wire macfb IRQ to separate video interrupt on VIA2Mark Cave-Ayland1-2/+5
Whilst the in-built Quadra 800 framebuffer exists within the Nubus address space for slot 9, it has its own dedicated interrupt on VIA2. Force the macfb device to occupy slot 9 in the q800 machine and wire its IRQ to the separate video interrupt since this is what is expected by the MacOS interrupt handler. 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-14-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-08macfb: add vertical blank interruptMark Cave-Ayland2-0/+91
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: fix 24-bit RGB pixel encodingMark Cave-Ayland1-4/+4
According to Apple Technical Note HW26: "Macintosh Quadra Built-In Video" the in-built framebuffer encodes each 24-bit pixel into 4 bytes. Adjust the 24-bit RGB pixel encoding accordingly which agrees with the encoding expected by MacOS when changing into 24-bit colour mode. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211007221253.29024-12-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-08macfb: fix up 1-bit pixel encodingMark Cave-Ayland1-1/+3
The MacOS driver expects the RGB values for the pixel to be in entries 0 and 1 of the colour palette. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211007221253.29024-11-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-Ayland4-21/+156
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-Ayland3-1/+12
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-Ayland3-2/+137
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-08macfb: add trace events for reading and writing the control registersMark Cave-Ayland2-1/+11
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-7-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-08macfb: use memory_region_init_ram() in macfb_common_realize() for the ↵Mark Cave-Ayland1-3/+2
framebuffer Currently macfb_common_realize() defines the framebuffer RAM memory region as being non-migrateable but then immediately registers it for migration. Replace memory_region_init_ram_nomigrate() with memory_region_init_ram() which is clearer and does exactly the same thing. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211007221253.29024-6-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-08macfb: fix overflow of color_palette arrayMark Cave-Ayland1-1/+3
The palette_current index counter has a maximum size of 256 * 3 to cover a full color palette of 256 RGB entries. Linux assumes that the palette_current index wraps back around to zero after writing 256 RGB entries so ensure that palette_current is reset at this point to prevent data corruption within MacfbState. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211007221253.29024-5-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-08macfb: fix invalid object reference in macfb_common_realize()Mark Cave-Ayland1-1/+1
During realize memory_region_init_ram_nomigrate() is used to initialise the RAM memory region used for the framebuffer but the owner object reference is incorrect since MacFbState is a typedef and not a QOM type. Change the memory region owner to be the corresponding DeviceState to fix the issue and prevent random crashes during macfb_common_realize(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: 8ac919a0654 ("hw/m68k: add Nubus macfb video card") Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211007221253.29024-4-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-08macfb: update macfb.c to use the Error API best practicesMark Cave-Ayland1-8/+8
As per the current Error API best practices, change macfb_commom_realize() to return a boolean indicating success to reduce errp boiler-plate handling code. Note that memory_region_init_ram_nomigrate() is also updated to use &error_abort to indicate a non-recoverable error, matching the behaviour recommended after similar discussions on memory API failures for the recent nubus changes. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211007221253.29024-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-08macfb: handle errors that occur during realizeMark Cave-Ayland1-0/+11
Make sure any errors that occur within the macfb realize chain are detected and handled correctly to prevent crashes and to ensure that error messages are reported back to the user. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211007221253.29024-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-07Merge remote-tracking branch ↵Richard Henderson12-92/+316
'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-07iothread: use IOThreadParamInfo in iothread_[set|get]_param()Stefano Garzarella1-8/+10
Commit 0445409d74 ("iothread: generalize iothread_set_param/iothread_get_param") moved common code to set and get IOThread parameters in two new functions. These functions are called inside callbacks, so we don't need to use an opaque pointer. Let's replace `void *opaque` parameter with `IOThreadParamInfo *info`. Suggested-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210727145936.147032-3-sgarzare@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-10-07iothread: rename PollParamInfo to IOThreadParamInfoStefano Garzarella1-7/+7
Commit 1793ad0247 ("iothread: add aio-max-batch parameter") added a new parameter (aio-max-batch) to IOThread and used PollParamInfo structure to handle it. Since it is not a parameter of the polling mechanism, we rename the structure to a more generic IOThreadParamInfo. Suggested-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210727145936.147032-2-sgarzare@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-10-07Merge remote-tracking branch ↵Richard Henderson15-479/+516
'remotes/alistair23/tags/pull-riscv-to-apply-20211007' into staging Third RISC-V PR for QEMU 6.2 - Add Zb[abcs] instruction support - Remove RVB support - Bug fix of setting mstatus_hs.[SD|FS] bits - Mark some UART devices as 'input' - QOMify PolarFire MMUART - Fixes for sifive PDMA - Mark shakti_c as not user creatable # gpg: Signature made Wed 06 Oct 2021 11:42:53 PM PDT # gpg: using RSA key F6C4AC46D4934868D3B8CE8F21E10D29DF977054 # gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [full] * remotes/alistair23/tags/pull-riscv-to-apply-20211007: (26 commits) hw/riscv: shakti_c: Mark as not user creatable hw/dma: sifive_pdma: Don't run DMA when channel is disclaimed hw/dma: sifive_pdma: Fix Control.claim bit detection hw/char/mchp_pfsoc_mmuart: QOM'ify PolarFire MMUART hw/char/mchp_pfsoc_mmuart: Use a MemoryRegion container hw/char/mchp_pfsoc_mmuart: Simplify MCHP_PFSOC_MMUART_REG definition hw/char: sifive_uart: Register device in 'input' category hw/char: shakti_uart: Register device in 'input' category hw/char: ibex_uart: Register device in 'input' category target/riscv: Set mstatus_hs.[SD|FS] bits if Clean and V=1 in mark_fs_dirty() disas/riscv: Add Zb[abcs] instructions target/riscv: Remove RVB (replaced by Zb[abcs]) target/riscv: Add zext.h instructions to Zbb, removing pack/packu/packh target/riscv: Add rev8 instruction, removing grev/grevi target/riscv: Add a REQUIRE_32BIT macro target/riscv: Add orc.b instruction for Zbb, removing gorc/gorci target/riscv: Reassign instructions to the Zbb-extension target/riscv: Add instructions of the Zbc-extension target/riscv: Reassign instructions to the Zbs-extension target/riscv: Remove shift-one instructions (proposed Zbo in pre-0.93 draft-B) ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-07iotests: Add mirror-ready-cancel-error testHanna Reitz2-0/+148
Test what happens when there is an I/O error after a mirror job in the READY phase has been cancelled. Signed-off-by: Hanna Reitz <hreitz@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Tested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20211006151940.214590-14-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07mirror: Do not clear .cancelledHanna Reitz2-3/+3
Clearing .cancelled before leaving the main loop when the job has been soft-cancelled is no longer necessary since job_is_cancelled() only returns true for jobs that have been force-cancelled. Therefore, this only makes a differences in places that call job_cancel_requested(). In block/mirror.c, this is done only before .cancelled was cleared. In job.c, there are two callers: - job_completed_txn_abort() asserts that .cancelled is true, so keeping it true will not affect this place. - job_complete() refuses to let a job complete that has .cancelled set. It is correct to refuse to let the user invoke job-complete on mirror jobs that have already been soft-cancelled. With this change, there are no places that reset .cancelled to false and so we can be sure that .force_cancel can only be true if .cancelled is true as well. Assert this in job_is_cancelled(). 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-13-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07mirror: Stop active mirroring after force-cancelHanna Reitz1-0/+2
Once the mirror job is force-cancelled (job_is_cancelled() is true), we should not generate new I/O requests. This applies to active mirroring, too, so stop it once the job is cancelled. (We must still forward all I/O requests to the source, though, of course, but those are not really I/O requests generated by the job, so this is fine.) 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-12-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07mirror: Check job_is_cancelled() earlierHanna Reitz1-5/+5
We must check whether the job is force-cancelled early in our main loop, most importantly before any `continue` statement. For example, we used to have `continue`s before our current checking location that are triggered by `mirror_flush()` failing. So, if `mirror_flush()` kept failing, force-cancelling the job would not terminate it. Jobs can be cancelled while they yield, and once they are (force-cancelled), they should not generate new I/O requests. Therefore, we should put the check after the last yield before mirror_iteration() is invoked. 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-11-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07mirror: Use job_is_cancelled()Hanna Reitz1-1/+1
mirror_drained_poll() returns true whenever the job is cancelled, because "we [can] be sure that it won't issue more requests". However, this is only true for force-cancelled jobs, so use job_is_cancelled(). 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-10-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07job: Add job_cancel_requested()Hanna Reitz3-9/+23
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-07job: Do not soft-cancel after a job is doneHanna Reitz1-4/+21
The only job that supports a soft cancel mode is the mirror job, and in such a case it resets its .cancelled field before it leaves its .run() function, so it does not really count as cancelled. However, it is possible to cancel the job after .run() returns and before job_exit() (which is run in the main loop) is executed. Then, .cancelled would still be true and the job would count as cancelled. This does not seem to be in the interest of the mirror job, so adjust job_cancel_async() to not set .cancelled in such a case, and job_cancel() to not invoke job_completed_txn_abort(). 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-8-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07jobs: Give Job.force_cancel more meaningHanna Reitz4-9/+35
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 Reitz7-50/+50
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-07job: Force-cancel jobs in a failed transactionHanna Reitz1-1/+6
When a transaction is aborted, no result matters, and so all jobs within should be force-cancelled. 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-5-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07mirror: Drop s->syncedHanna Reitz1-10/+9
As of HEAD^, there is no meaning to s->synced other than whether the job is READY or not. job_is_ready() gives us that information, too. Suggested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 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-4-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07mirror: Keep s->synced on errorHanna Reitz1-1/+0
An error does not take us out of the READY phase, which is what s->synced signifies. It does of course mean that source and target are no longer in sync, but that is what s->actively_sync is for -- s->synced never meant that source and target are in sync, only that they were at some point (and at that point we transitioned into the READY phase). The tangible problem is that we transition to READY once we are in sync and s->synced is false. By resetting s->synced here, we will transition from READY to READY once the error is resolved (if the job keeps running), and that transition is not allowed. Signed-off-by: Hanna Reitz <hreitz@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20211006151940.214590-3-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07job: Context changes in job_completed_txn_abort()Hanna Reitz1-5/+17
Finalizing the job may cause its AioContext to change. This is noted by job_exit(), which points at job_txn_apply() to take this fact into account. However, job_completed() does not necessarily invoke job_txn_apply() (through job_completed_txn_success()), but potentially also job_completed_txn_abort(). The latter stores the context in a local variable, and so always acquires the same context at its end that it has released in the beginning -- which may be a different context from the one that job_exit() releases at its end. If it is different, qemu aborts ("qemu_mutex_unlock_impl: Operation not permitted"). Drop the local @outer_ctx variable from job_completed_txn_abort(), and instead re-acquire the actual job's context at the end of the function, so job_exit() will release the same. Signed-off-by: Hanna Reitz <hreitz@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20211006151940.214590-2-hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2021-10-07hw/riscv: shakti_c: Mark as not user creatableAlistair Francis1-0/+7
Mark the shakti_c machine as not user creatable. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/639 Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <c617a04d4e3dd041a3427b47a1b1d5ab475a2edd.1632871759.git.alistair.francis@wdc.com>
2021-10-07hw/dma: sifive_pdma: Don't run DMA when channel is disclaimedBin Meng1-2/+9
If Control.run bit is set while not preserving the Control.claim bit, the DMA transfer shall not be started. The following result is PDMA tested in U-Boot on Unleashed board: => mw.l 0x3000000 0x0 <= Disclaim channel 0 => mw.l 0x3000000 0x1 <= Claim channel 0 => mw.l 0x3000004 0x55000000 <= wsize = rsize = 5 (2^5 = 32 bytes) => mw.q 0x3000008 0x2 <= NextBytes = 2 => mw.q 0x3000010 0x84000000 <= NextDestination = 0x84000000 => mw.q 0x3000018 0x84001000 <= NextSource = 0x84001000 => mw.l 0x84000000 0x87654321 <= Fill test data to dst => mw.l 0x84001000 0x12345678 <= Fill test data to src => md.l 0x84000000 1; md.l 0x84001000 1 <= Dump src/dst memory contents 84000000: 87654321 !Ce. 84001000: 12345678 xV4. => md.l 0x3000000 8 <= Dump PDMA status 03000000: 00000001 55000000 00000002 00000000 .......U........ 03000010: 84000000 00000000 84001000 00000000 ................ => mw.l 0x3000000 0x2 <= Set channel 0 run bit only => md.l 0x3000000 8 <= Dump PDMA status 03000000: 00000000 55000000 00000002 00000000 .......U........ 03000010: 84000000 00000000 84001000 00000000 ................ => md.l 0x84000000 1; md.l 0x84001000 1 <= Dump src/dst memory contents 84000000: 87654321 !Ce. 84001000: 12345678 xV4. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210927072124.1564129-2-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-07hw/dma: sifive_pdma: Fix Control.claim bit detectionBin Meng1-1/+1
At present the codes detect whether the DMA channel is claimed by: claimed = !!s->chan[ch].control & CONTROL_CLAIM; As ! has higher precedence over & (bitwise and), this is essentially claimed = (!!s->chan[ch].control) & CONTROL_CLAIM; which is wrong, as any non-zero bit set in the control register will produce a result of a claimed channel. Fixes: de7c7988d25d ("hw/dma: sifive_pdma: reset Next* registers when Control.claim is set") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210927072124.1564129-1-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-07hw/char/mchp_pfsoc_mmuart: QOM'ify PolarFire MMUARTPhilippe Mathieu-Daudé2-16/+93
- 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é2-3/+9
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é2-8/+10
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-07hw/char: sifive_uart: Register device in 'input' categoryBin Meng1-0/+1
The category of sifive_uart device is not set. Put it into the 'input' category. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210926105003.2716-3-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-07hw/char: shakti_uart: Register device in 'input' categoryBin Meng1-0/+1
The category of shakti_uart device is not set. Put it into the 'input' category. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210926105003.2716-2-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-07hw/char: ibex_uart: Register device in 'input' categoryBin Meng1-0/+1
The category of ibex_uart device is not set. Put it into the 'input' category. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210926105003.2716-1-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-07target/riscv: Set mstatus_hs.[SD|FS] bits if Clean and V=1 in mark_fs_dirty()Frank Chang2-13/+21
When V=1, both vsstauts.FS and HS-level sstatus.FS are in effect. Modifying the floating-point state when V=1 causes both fields to be set to 3 (Dirty). However, it's possible that HS-level sstatus.FS is Clean and VS-level vsstatus.FS is Dirty at the time mark_fs_dirty() is called when V=1. We can't early return for this case because we still need to set sstatus.FS to Dirty according to spec. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Vincent Chen <vincent.chen@sifive.com> Tested-by: Vincent Chen <vincent.chen@sifive.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210921020234.123448-1-frank.chang@sifive.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-07disas/riscv: Add Zb[abcs] instructionsPhilipp Tomsich1-3/+154
With the addition of Zb[abcs], we also need to add disassembler support for these new instructions. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210911140016.834071-17-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-07target/riscv: Remove RVB (replaced by Zb[abcs])Philipp Tomsich3-33/+0
With everything classified as Zb[abcs] and pre-0.93 draft-B instructions that are not part of Zb[abcs] removed, we can remove the remaining support code for RVB. Note that RVB has been retired for good and misa.B will neither mean 'some' or 'all of' Zb*: https://lists.riscv.org/g/tech-bitmanip/message/532 Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20210911140016.834071-16-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-07target/riscv: Add zext.h instructions to Zbb, removing pack/packu/packhPhilipp Tomsich2-77/+21
The 1.0.0 version of Zbb does not contain pack/packu/packh. However, a zext.h instruction is provided (built on pack/packh from pre-0.93 draft-B) is available. This commit adds zext.h and removes the pack* instructions. Note that the encodings for zext.h are different between RV32 and RV64, which is handled through REQUIRE_32BIT. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210911140016.834071-15-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-07target/riscv: Add rev8 instruction, removing grev/greviPhilipp Tomsich4-79/+15
The 1.0.0 version of Zbb does not contain grev/grevi. Instead, a rev8 instruction (equivalent to the rev8 pseudo-instruction built on grevi from pre-0.93 draft-B) is available. This commit adds the new rev8 instruction and removes grev/grevi. Note that there is no W-form of this instruction (both a sign-extending and zero-extending 32-bit version can easily be synthesized by following rev8 with either a srai or srli instruction on RV64) and that the opcode encodings for rev8 in RV32 and RV64 are different. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210911140016.834071-14-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
generated by cgit v1.1 at 2024-12-27 12:59:27 +0000