Merge remote-tracking branch 'remotes/stsquad/tags/pull-for-6.2-121021-2' into staging
Some testing and plugin updates:
- don't override the test compiler when specified
- split some multiarch tests by guest OS
- add riscv64 docker image and cross-compile tests
- drop release tarball test from Travis
- skip check-patch on master repo
- fix passing of TEST_TARGETS to cirrus
- fix missing symbols in plugins
- ensure s390x insn start ops precede plugin instrumentation
- refactor plugin instruction boundary detection
- update github repo lockdown
- add a debian-native test image for multi-arch builds
* remotes/stsquad/tags/pull-for-6.2-121021-2:
tests/docker: add a debian-native image and make available
.github: move repo lockdown to the v2 configuration
accel/tcg: re-factor plugin_inject_cb so we can assert insn_idx is valid
target/s390x: move tcg_gen_insn_start to s390x_tr_insn_start
plugins/: Add missing functions to symbol list
gitlab: fix passing of TEST_TARGETS env to cirrus
gitlab: skip the check-patch job on the upstream repo
travis.yml: Remove the "Release tarball" job
gitlab: Add cross-riscv64-system, cross-riscv64-user
tests/docker: promote debian-riscv64-cross to a full image
tests/tcg: move some multiarch files and make conditional
tests/tcg/sha1: remove endian include
configure: don't override the selected host test compiler if defined
Merge remote-tracking branch 'remotes/clg/tags/pull-aspeed-20211012' into staging
Aspeed patches :
* I2C QOMify (Cedric)
* SMC model cleanup and QOMify (Cedric)
* ADC model (Peter and Andrew)
* GPIO fixes (Peter)
# gpg: Signature made Tue 12 Oct 2021 12:36:22 AM PDT
# gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1
# gpg: Good signature from "Cédric Le Goater <[email protected]>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1
* remotes/clg/tags/pull-aspeed-20211012:
aspeed/smc: Dump address offset in trace events
aspeed/wdt: Add trace events
hw/arm: Integrate ADC model into Aspeed SoC
hw/adc: Add basic Aspeed ADC model
hw: aspeed_gpio: Fix GPIO array indexing
hw: aspeed_gpio: Fix pin I/O type declarations
aspeed/i2c: QOMify AspeedI2CBus
aspeed/smc: Remove unused attribute 'irqline'
aspeed/smc: Introduce a new addr_width() class handler
aspeed/smc: Add default reset values
aspeed/smc: QOMify AspeedSMCFlash
aspeed/smc: Rename AspeedSMCFlash 'id' to 'cs'
aspeed/smc: Remove the 'size' attribute from AspeedSMCFlash
aspeed/smc: Remove the 'flash' attribute from AspeedSMCFlash
aspeed/smc: Drop AspeedSMCController structure
aspeed/smc: Stop using the model name for the memory regions
aspeed/smc: Introduce aspeed_smc_error() helper
aspeed/smc: Add watchdog Control/Status Registers
Alex Bennée [Wed, 22 Sep 2021 15:15:27 +0000 (16:15 +0100)]
tests/docker: add a debian-native image and make available
This image is intended for building whatever the native versions of
QEMU are for the host architecture. This will hopefully be an aid for
3rd parties who want to be able to build QEMU themselves without
redoing all the dependencies themselves.
We disable the registry because we currently don't have multi-arch
support there.
Alex Bennée [Mon, 4 Oct 2021 15:43:08 +0000 (16:43 +0100)]
.github: move repo lockdown to the v2 configuration
I was getting prompted by GitHub for new permissions but it turns out
per https://github.com/dessant/repo-lockdown/issues/6:
Repo Lockdown has been rewritten for GitHub Actions, offering new
features and better control over your automation presets. The legacy
GitHub App has been deprecated, and the public instance of the app
has been shut down.
So this is what I've done. As the issues tab is disabled I've removed
the handling for issues from the new version.
Alex Bennée [Fri, 17 Sep 2021 16:23:32 +0000 (17:23 +0100)]
accel/tcg: re-factor plugin_inject_cb so we can assert insn_idx is valid
Coverity doesn't know enough about how we have arranged our plugin TCG
ops to know we will always have incremented insn_idx before injecting
the callback. Let us assert it for the benefit of Coverity and protect
ourselves from accidentally breaking the assumption and triggering
harder to grok errors deeper in the code if we attempt a negative
indexed array lookup.
However to get to this point we re-factor the code and remove the
second hand instruction boundary detection in favour of scanning the
full set of ops and using the existing INDEX_op_insn_start to cleanly
detect when the instruction has started. As we no longer need the
plugin specific list of ops we delete that.
My initial benchmarks shows no discernible impact of dropping the
plugin specific ops list.
target/s390x: move tcg_gen_insn_start to s390x_tr_insn_start
We use INDEX_op_insn_start to make the start of instruction boundaries.
If we don't do it in the .insn_start hook things get confused especially
now plugins want to use that marking to identify the start of instructions
and will bomb out if it sees instrumented ops before the first instruction
boundary.
Some functions of the plugin API were missing in
the symbol list. However, they are all used by
the contributed example plugins. QEMU fails to
load the plugin if the function symbol is not
exported.
gitlab: skip the check-patch job on the upstream repo
The check-patch job is intended to be used by contributors or
subsystem maintainers to see if there are style mistakes. The
false positive rate is too high to be used in a gating scenario
so should not run it on the upstream repo ever.
Thomas Huth [Fri, 17 Sep 2021 16:23:28 +0000 (17:23 +0100)]
travis.yml: Remove the "Release tarball" job
This is a leftover from the days when we were using Travis excessively,
but since x86 jobs are not really usable there anymore, this job has
likely never been used since many months. Let's simply remove it now.
Alex Bennée [Fri, 17 Sep 2021 16:23:25 +0000 (17:23 +0100)]
tests/docker: promote debian-riscv64-cross to a full image
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.
Alex Bennée [Fri, 17 Sep 2021 16:23:24 +0000 (17:23 +0100)]
tests/tcg: move some multiarch files and make conditional
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.
Alex Bennée [Fri, 17 Sep 2021 16:23:22 +0000 (17:23 +0100)]
configure: don't override the selected host test compiler if defined
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.
Andrew Jeffery [Tue, 12 Oct 2021 06:20:08 +0000 (08:20 +0200)]
hw/adc: Add basic Aspeed ADC model
This model implements enough behaviour to do basic functionality tests
such as device initialisation and read out of dummy sample values. The
sample value generation strategy is similar to the STM ADC already in
the tree.
Signed-off-by: Andrew Jeffery <[email protected]>
[clg : support for multiple engines (AST2600) ] Signed-off-by: Cédric Le Goater <[email protected]>
[pdel : refactored engine register struct fields to regs[] array field]
[pdel : added guest-error checking for upper-8 channel regs in AST2600]
[pdel : allow 16-bit reads of the channel data registers] Signed-off-by: Peter Delevoryas <[email protected]>
Message-Id: <20211005052604.1674891[email protected]> Signed-off-by: Cédric Le Goater <[email protected]>
This can result in an out-of-bounds access to "s->gpios" because the
gpio sets do _not_ have the same length. Some of the groups (e.g.
GPIOAB) only have 4 pins. 228 != 8 * 32 == 256.
To fix this, I converted the gpio array from dense to sparse, to that
match both the hardware layout and this existing indexing code.
Peter Delevoryas [Tue, 12 Oct 2021 06:20:08 +0000 (08:20 +0200)]
hw: aspeed_gpio: Fix pin I/O type declarations
Some of the pin declarations in the Aspeed GPIO module were incorrect,
probably because of confusion over which bits in the input and output
uint32_t's correspond to which groups in the label array. Since the
uint32_t literals are in big endian, it's sort of the opposite of what
would be intuitive. The least significant bit in ast2500_set_props[6]
corresponds to GPIOY0, not GPIOAB7.
GPIOxx indicates input and output capabilities, GPIxx indicates only
input, GPOxx indicates only output.
AST2500:
- Previously had GPIW0..GPIW7 and GPIX0..GPIX7, that's correct.
- Previously had GPIOY0..GPIOY3, should have been GPIOY0..GPIOY7.
- Previously had GPIOAB0..GPIOAB3 and GPIAB4..GPIAB7, should only have
been GPIOAB0..GPIOAB3.
AST2600:
- GPIOT0..GPIOT7 should have been GPIT0..GPIT7.
- GPIOU0..GPIOU7 should have been GPIU0..GPIU7.
- GPIW0..GPIW7 should have been GPIOW0..GPIOW7.
- GPIOY0..GPIOY7 and GPIOZ0...GPIOZ7 were disabled.
Cédric Le Goater [Tue, 12 Oct 2021 06:20:08 +0000 (08:20 +0200)]
aspeed/i2c: QOMify AspeedI2CBus
Introduce an AspeedI2CBus SysBusDevice model and attach the associated
memory region and IRQ to the newly instantiated objects.
Before this change, the I2C bus IRQs were all attached to the
SysBusDevice model of the I2C controller. Adapt the AST2600 SoC
realize routine to take into account this change.
Cédric Le Goater [Tue, 12 Oct 2021 06:20:08 +0000 (08:20 +0200)]
aspeed/smc: Introduce a new addr_width() class handler
The AST2400 SPI controller has a transitional HW interface and it
stores the address width currently in use in a different register than
all the other SMC controllers. It needs special handling when working
in 4B mode.
Make it clear through a class handler. This also removes another use
of the segments array.
Cédric Le Goater [Tue, 12 Oct 2021 06:20:08 +0000 (08:20 +0200)]
aspeed/smc: Remove the 'flash' attribute from AspeedSMCFlash
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.
Cédric Le Goater [Tue, 12 Oct 2021 06:20:08 +0000 (08:20 +0200)]
aspeed/smc: Drop AspeedSMCController structure
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.
Cédric Le Goater [Tue, 12 Oct 2021 06:20:08 +0000 (08:20 +0200)]
aspeed/smc: Stop using the model name for the memory regions
There is no real reason to use this name. It's simply nice to have in
the monitor output but it's a burden for the following patch which
removes the AspeedSMCController structure describing the controller.
Cédric Le Goater [Tue, 12 Oct 2021 06:20:07 +0000 (08:20 +0200)]
aspeed/smc: Add watchdog Control/Status Registers
The Aspeed SoCs have a dual boot function for firmware fail-over
recovery. The system auto-reboots from the second flash if the main
flash does not boot successfully within a certain amount of time. This
function is called alternate boot (ABR) in the FMC controllers.
On AST2400/AST2500, ABR is enabled by hardware strapping in SCU70 to
enable the 2nd watchdog timer, on AST2600, through register SCU510.
If the boot on the the main flash succeeds, the firmware should
disable the 2nd watchdog timer. If not, the BMC is reset and the CE0
and CE1 mappings are swapped to restart the BMC from the 2nd flash.
On the AST2600, the ABR registers controlling the 2nd watchdog timer
were moved from the watchdog register to the FMC controller and the
FMC model should be able to control WDT2 through its own register set.
This requires more work. For now, add dummy read/write handlers to let
the FW disable the 2nd watchdog without error.
* remotes/stefanha/tags/block-pull-request:
iothread: use IOThreadParamInfo in iothread_[set|get]_param()
iothread: rename PollParamInfo to IOThreadParamInfo
* 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
q800: wire macfb IRQ to separate video interrupt on VIA2
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.
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.
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.
macfb: add common monitor modes supported by the MacOS toolbox ROM
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.
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.
macfb: implement mode sense to allow display type to be detected
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.
macfb: use memory_region_init_ram() in macfb_common_realize() for the 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.
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.
macfb: fix invalid object reference in macfb_common_realize()
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().
macfb: update macfb.c to use the Error API best practices
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.
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.
Merge remote-tracking branch '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 <[email protected]>" [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`
iothread: use IOThreadParamInfo in iothread_[set|get]_param()
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`.
iothread: rename PollParamInfo to IOThreadParamInfo
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.
Merge remote-tracking branch '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
* 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)
...
Hanna Reitz [Wed, 6 Oct 2021 15:19:39 +0000 (17:19 +0200)]
mirror: Do not clear .cancelled
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().
Hanna Reitz [Wed, 6 Oct 2021 15:19:38 +0000 (17:19 +0200)]
mirror: Stop active mirroring after force-cancel
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.)
Hanna Reitz [Wed, 6 Oct 2021 15:19:37 +0000 (17:19 +0200)]
mirror: Check job_is_cancelled() earlier
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.
Hanna Reitz [Wed, 6 Oct 2021 15:19:36 +0000 (17:19 +0200)]
mirror: Use job_is_cancelled()
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().
Hanna Reitz [Wed, 6 Oct 2021 15:19:35 +0000 (17:19 +0200)]
job: Add job_cancel_requested()
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.)
Hanna Reitz [Wed, 6 Oct 2021 15:19:34 +0000 (17:19 +0200)]
job: Do not soft-cancel after a job is done
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().
Hanna Reitz [Wed, 6 Oct 2021 15:19:33 +0000 (17:19 +0200)]
jobs: Give Job.force_cancel more meaning
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.
Hanna Reitz [Wed, 6 Oct 2021 15:19:32 +0000 (17:19 +0200)]
job: @force parameter for job_cancel_sync()
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.)
Hanna Reitz [Wed, 6 Oct 2021 15:19:29 +0000 (17:19 +0200)]
mirror: Keep s->synced on error
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.
Hanna Reitz [Wed, 6 Oct 2021 15:19:28 +0000 (17:19 +0200)]
job: Context changes in job_completed_txn_abort()
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.
- 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.
hw/char/mchp_pfsoc_mmuart: Use a MemoryRegion container
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.
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:
Frank Chang [Tue, 21 Sep 2021 02:02:33 +0000 (10:02 +0800)]
target/riscv: Set mstatus_hs.[SD|FS] bits if Clean and V=1 in mark_fs_dirty()
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.
Philipp Tomsich [Sat, 11 Sep 2021 14:00:15 +0000 (16:00 +0200)]
target/riscv: Remove RVB (replaced by Zb[abcs])
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
Philipp Tomsich [Sat, 11 Sep 2021 14:00:14 +0000 (16:00 +0200)]
target/riscv: Add zext.h instructions to Zbb, removing pack/packu/packh
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.
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.
Philipp Tomsich [Sat, 11 Sep 2021 14:00:12 +0000 (16:00 +0200)]
target/riscv: Add a REQUIRE_32BIT macro
With the changes to Zb[abcs], there's some encodings that are
different in RV64 and RV32 (e.g., for rev8 and zext.h). For these,
we'll need a helper macro allowing us to select on RV32, as well.
Philipp Tomsich [Sat, 11 Sep 2021 14:00:11 +0000 (16:00 +0200)]
target/riscv: Add orc.b instruction for Zbb, removing gorc/gorci
The 1.0.0 version of Zbb does not contain gorc/gorci. Instead, a
orc.b instruction (equivalent to the orc.b pseudo-instruction built on
gorci from pre-0.93 draft-B) is available, mainly targeting
string-processing workloads.
This commit adds the new orc.b instruction and removed gorc/gorci.
Philipp Tomsich [Sat, 11 Sep 2021 14:00:10 +0000 (16:00 +0200)]
target/riscv: Reassign instructions to the Zbb-extension
This reassigns the instructions that are part of Zbb into it, with the
notable exceptions of the instructions (rev8, zext.w and orc.b) that
changed due to gorci, grevi and pack not being part of Zb[abcs].
Philipp Tomsich [Sat, 11 Sep 2021 14:00:09 +0000 (16:00 +0200)]
target/riscv: Add instructions of the Zbc-extension
The following instructions are part of Zbc:
- clmul
- clmulh
- clmulr
Note that these instructions were already defined in the pre-0.93 and
the 0.93 draft-B proposals, but had not been omitted in the earlier
addition of draft-B to QEmu.
Philipp Tomsich [Sat, 11 Sep 2021 14:00:07 +0000 (16:00 +0200)]
target/riscv: Remove shift-one instructions (proposed Zbo in pre-0.93 draft-B)
The Zb[abcs] ratification package does not include the proposed
shift-one instructions. There currently is no clear plan to whether
these (or variants of them) will be ratified as Zbo (or a different
extension) or what the timeframe for such a decision could be.
Philipp Tomsich [Sat, 11 Sep 2021 14:00:06 +0000 (16:00 +0200)]
target/riscv: Remove the W-form instructions from Zbs
Zbs 1.0.0 (just as the 0.93 draft-B before) does not provide for W-form
instructions for Zbs (single-bit instructions). Remove them.
Note that these instructions had already been removed for the 0.93
version of the draft-B extention and have not been present in the
binutils patches circulating in January 2021.
Philipp Tomsich [Sat, 11 Sep 2021 14:00:04 +0000 (16:00 +0200)]
target/riscv: Add x-zba, x-zbb, x-zbc and x-zbs properties
The bitmanipulation ISA extensions will be ratified as individual
small extension packages instead of a large B-extension. The first
new instructions through the door (these have completed public review)
are Zb[abcs].
This adds new 'x-zba', 'x-zbb', 'x-zbc' and 'x-zbs' properties for
these in target/riscv/cpu.[ch].
Philipp Tomsich [Sat, 11 Sep 2021 14:00:03 +0000 (16:00 +0200)]
target/riscv: clwz must ignore high bits (use shift-left & changed logic)
Assume clzw being executed on a register that is not sign-extended, such
as for the following sequence that uses (1ULL << 63) | 392 as the operand
to clzw:
bseti a2, zero, 63
addi a2, a2, 392
clzw a3, a2
The correct result of clzw would be 23, but the current implementation
returns -32 (as it performs a 64bit clz, which results in 0 leading zero
bits, and then subtracts 32).
Fix this by changing the implementation to:
1. shift the original register up by 32
2. performs a target-length (64bit) clz
3. return 32 if no bits are set
Marking this instruction as 'w-form' (i.e., setting ctx->w) would not
correctly model the behaviour, as the instruction should not perform
a zero-extensions on the input (after all, it is not a .uw instruction)
and the result is always in the range 0..32 (so neither a sign-extension
nor a zero-extension on the result will ever be needed). Consequently,
we do not set ctx->w and mark the instruction as EXT_NONE.
Philipp Tomsich [Sat, 11 Sep 2021 14:00:01 +0000 (16:00 +0200)]
target/riscv: Introduce temporary in gen_add_uw()
Following the recent changes in translate.c, gen_add_uw() causes
failures on CF3 and SPEC2017 due to the reuse of arg1. Fix these
regressions by introducing a temporary.
Merge remote-tracking branch 'remotes/quic/tags/pull-hex-20211006' into staging
Change from Philippe - Use tcg_constant_*
Change from Philippe - Remove unused TCG temp
Change from Taylor - Probe the stores in a packet at start of commit
# gpg: Signature made Wed 06 Oct 2021 08:44:13 AM PDT
# gpg: using RSA key 7B0244FB12DE4422
# gpg: Good signature from "Taylor Simpson (Rock on) <[email protected]>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 3635 C788 CE62 B91F D4C5 9AB4 7B02 44FB 12DE 4422
* remotes/quic/tags/pull-hex-20211006:
target/hexagon: Use tcg_constant_*
target/hexagon: Remove unused TCG temporary from predicated loads
Hexagon (target/hexagon) probe the stores in a packet at start of commit
Taylor Simpson [Wed, 22 Sep 2021 15:30:46 +0000 (10:30 -0500)]
Hexagon (target/hexagon) probe the stores in a packet at start of commit
When a packet has 2 stores, either both commit or neither commit.
At the beginning of gen_commit_packet, we check for multiple stores.
If there are multiple stores, call a helper that will probe each of
them before proceeding with the commit.
Note that we don't call the probe helper for packets with only one
store. Therefore, we call process_store_log before anything else
involved in committing the packet.
We also fix a typo in the comment in process_store_log.
Test case added in tests/tcg/hexagon/hex_sigsegv.c
Merge remote-tracking branch 'remotes/kwolf/tags/for-upstream' into staging
Block layer patches
- Fix I/O errors because of incorrectly detected max_iov
- Fix not white-listed copy-before-write
- qemu-storage-daemon: Only display FUSE help when FUSE is built-in
- iotests: update environment and linting configuration
* remotes/kwolf/tags/for-upstream:
iotests: Update for pylint 2.11.1
iotests/migrate-bitmaps-test: delint
iotests/mirror-top-perms: Adjust imports
iotests/linters: check mypy files all at once
iotests: add 'qemu' package location to PYTHONPATH in testenv
block: introduce max_hw_iov for use in scsi-generic
iotests/image-fleecing: declare requirement of copy-before-write
block: bdrv_insert_node(): don't use bdrv_open()
block: bdrv_insert_node(): doc and style
block: bdrv_insert_node(): fix and improve error handling
block: implement bdrv_new_open_driver_opts()
qemu-storage-daemon: Only display FUSE help when FUSE is built-in
include/block.h: remove outdated comment
John Snow [Thu, 23 Sep 2021 18:07:14 +0000 (14:07 -0400)]
iotests/migrate-bitmaps-test: delint
Mostly uninteresting stuff. Move the test injections under a function
named main() so that the variables used during that process aren't in
the global scope.
projects / qemu.git / log