Acked-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210114100643.10617-2-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
virtio-fs qualifies as a bootable device minimally under OVMF, but
currently the necessary "bootindex" property is missing. Add the property.
Expose the property only in the PCI device, for now. There is no boot
support for virtiofs on s390x (ccw) for the time being [1] [2], so leave
the CCW device unchanged. Add the property to the base device still,
because adding the alias to the CCW device later will be easier this way
[3].
[1] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01745.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01870.html
[3] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01751.html
Example OpenFirmware device path for the "vhost-user-fs-pci" device in the
"bootorder" fw_cfg file:
/pci@i0cf8/pci-bridge@1,6/pci1af4,105a@0/filesystem@0
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Ján Tomko <jtomko@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: virtio-fs@redhat.com
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20210112131603.12686-1-lersek@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
When the slot is in steady powered-off state and the device is being
removed, there's no need to press the attention button. Nor is it
mandated by the Standard Hot-Plug Controller Specification, Rev. 1.0.
Moreover it confuses the guest, Linux in particular, as it assumes that
the attention button pressed in this state indicates that the device has
been inserted and will need to be powered on. Therefore it transitions
the slot into BLINKING_ON state for 5 seconds, and discovers at the end
that no device is actually inserted:
... unplug request
[12685.451329] shpchp 0000:01:00.0: Button pressed on Slot(2)
[12685.455478] shpchp 0000:01:00.0: PCI slot #2 - powering off due to button press
... in 5 seconds OS powers off the slot, QEMU ejects the device
[12690.632282] shpchp 0000:01:00.0: Latch open on Slot(2)
... excessive button press in steady powered-off state
[12690.634267] shpchp 0000:01:00.0: Button pressed on Slot(2)
[12690.636256] shpchp 0000:01:00.0: Card not present on Slot(2)
... the last button press spawns powering on the slot
[12690.638909] shpchp 0000:01:00.0: PCI slot #2 - powering on due to button press
... in 5 more seconds attempt to power on discovers empty slot
[12695.735986] shpchp 0000:01:00.0: No adapter on slot(2)
Worse, if the real device insertion happens within 5 seconds from the
apparent completion of the previous device removal (signaled via
DEVICE_DELETED event), the new button press will be interpreted as the
cancellation of that misguided powering on:
[13448.965295] shpchp 0000:01:00.0: Button pressed on Slot(2)
[13448.969430] shpchp 0000:01:00.0: PCI slot #2 - powering off due to button press
[13454.025107] shpchp 0000:01:00.0: Latch open on Slot(2)
[13454.027101] shpchp 0000:01:00.0: Button pressed on Slot(2)
[13454.029165] shpchp 0000:01:00.0: Card not present on Slot(2)
... the excessive button press spawns powering on the slot
... device has already been ejected by QEMU
[13454.031949] shpchp 0000:01:00.0: PCI slot #2 - powering on due to button press
... new device is inserted in the slot
[13456.861545] shpchp 0000:01:00.0: Latch close on Slot(2)
... valid button press arrives before 5 s since the wrong one
[13456.864894] shpchp 0000:01:00.0: Button pressed on Slot(2)
[13456.869211] shpchp 0000:01:00.0: Card present on Slot(2)
... the valid button press is counted as cancellation of the wrong one
[13456.873173] shpchp 0000:01:00.0: Button cancel on Slot(2)
[13456.877101] shpchp 0000:01:00.0: PCI slot #2 - action canceled due to button press
As a result, the newly inserted device isn't brought up by the guest.
Avoid this situation by not pushing the attention button when the device
in the slot is in powered-off state and is being ejected.
FWIW pcie implementation doesn't suffer from this problem.
Signed-off-by: Roman Kagan <rvkagan@yandex-team.ru>
Message-Id: <20201102053750.2281818-1-rvkagan@yandex-team.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* arm: Support emulation of ARMv8.4-TTST extension
* arm: Update cpu.h ID register field definitions
* arm: Fix breakage of XScale instruction emulation
* hw/net/lan9118: Fix RX Status FIFO PEEK value
* npcm7xx: Add ADC and PWM emulation
* ui/cocoa: Make "open docs" help menu entry work again when binary
is run from the build tree
* ui/cocoa: Fix openFile: deprecation on Big Sur
* docs: Add qemu-storage-daemon(1) manpage to meson.build
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAl/+EwcZHHBldGVyLm1h
eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3nnyEACgSVSXlYWWvt9FYUhrAL+U
QrCtCWon6Wt+T+gRHRPqYnnqLJ9jXsjEu7jxry2vvhRVk2GJvOOmdd0YBH7XJO6u
cuuVly2fRTn8XSjY1I8ul7oEt1XLRYlzqi8Cv3HAXBpgGDDQBby53PGmVQw0VXhf
GNSFG390P7sTdWk5VXBe0Eg0VTaePC/uHww2QkENmIM9uSqnemPxuW/2r94ez/7D
/QbdpOsW3aLDb6DyVN6kFX9cjIBiGpbi8uX4R1qwQ+r0COl8k/pNjTwnxMnHup3l
PK070EiL5X0IuGiwsdR8rlfkxZc4PYLxVRDCS4BfQXX2eyxiruBQbEWPrEUysKKf
stRLvNoQkcHmydjmzYfVNxe0LS2dAqFchdjSOwfjcF80yZKDOtXZBw0ZQHseUMT1
yiQawihXWWgL168rPxHyRxJGTRcrYpJciy65Yl+lwJGgzzrCu+1AuLrATiuKLzkt
y1eBWIE+7g5xtIuTiJnsQmxQPbToXT1zRV3NTufGk7UAt5JrbSKW5vte6/oChyen
Tyfvn/k2qsWmXFz3K/jucGS8TYPd2j5vbdSey6mfvbMQSnwvzi9DeinoIpnnz+GG
zuPVzvVxp9YuASFNSnG7L68g+8xpksju2p54c74uzN7g650NA7fGQ05HAeamPBf9
Xh9azPRjA5010WPt0AKtXQ==
=GPIT
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20210112-1' into staging
target-arm queue:
* arm: Support emulation of ARMv8.4-TTST extension
* arm: Update cpu.h ID register field definitions
* arm: Fix breakage of XScale instruction emulation
* hw/net/lan9118: Fix RX Status FIFO PEEK value
* npcm7xx: Add ADC and PWM emulation
* ui/cocoa: Make "open docs" help menu entry work again when binary
is run from the build tree
* ui/cocoa: Fix openFile: deprecation on Big Sur
* docs: Add qemu-storage-daemon(1) manpage to meson.build
# gpg: Signature made Tue 12 Jan 2021 21:22:15 GMT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* remotes/pmaydell/tags/pull-target-arm-20210112-1:
ui/cocoa: Fix openFile: deprecation on Big Sur
hw/*: Use type casting for SysBusDevice in NPCM7XX
hw/misc: Add QTest for NPCM7XX PWM Module
hw/misc: Add a PWM module for NPCM7XX
hw/adc: Add an ADC module for NPCM7XX
hw/timer: Refactor NPCM7XX Timer to use CLK clock
hw/misc: Add clock converter in NPCM7XX CLK module
hw/net/lan9118: Add symbolic constants for register offsets
hw/net/lan9118: Fix RX Status FIFO PEEK value
target/arm: Don't decode insns in the XScale/iWMMXt space as cp insns
docs: Add qemu-storage-daemon(1) manpage to meson.build
ui/cocoa: Update path to docs in build tree
target/arm: add aarch32 ID register fields to cpu.h
target/arm: add aarch64 ID register fields to cpu.h
target/arm: add descriptions of CLIDR_EL1, CCSIDR_EL1, CTR_EL0 to cpu.h
target/arm: make ARMCPU.ctr 64-bit
target/arm: make ARMCPU.clidr 64-bit
target/arm: fix typo in cpu.h ID_AA64PFR1 field name
target/arm: enable Small Translation tables in max CPU
target/arm: ARMv8.4-TTST extension
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
A device shouldn't access its parent object which is QOM internal.
Instead it should use type cast for this purporse. This patch fixes this
issue for all NPCM7XX Devices.
Signed-off-by: Hao Wu <wuhaotsh@google.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20210108190945.949196-7-wuhaotsh@google.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We add a qtest for the PWM in the previous patch. It proves it works as
expected.
Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com>
Reviewed-by: Tyrone Ting <kfting@nuvoton.com>
Signed-off-by: Hao Wu <wuhaotsh@google.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20210108190945.949196-6-wuhaotsh@google.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The PWM module is part of NPCM7XX module. Each NPCM7XX module has two
identical PWM modules. Each module contains 4 PWM entries. Each PWM has
two outputs: frequency and duty_cycle. Both are computed using inputs
from software side.
This module does not model detail pulse signals since it is expensive.
It also does not model interrupts and watchdogs that are dependant on
the detail models. The interfaces for these are left in the module so
that anyone in need for these functionalities can implement on their
own.
The user can read the duty cycle and frequency using qom-get command.
Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com>
Reviewed-by: Tyrone Ting <kfting@nuvoton.com>
Signed-off-by: Hao Wu <wuhaotsh@google.com>
Message-id: 20210108190945.949196-5-wuhaotsh@google.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The ADC is part of NPCM7XX Module. Its behavior is controled by the
ADC_CON register. It converts one of the eight analog inputs into a
digital input and stores it in the ADC_DATA register when enabled.
Users can alter input value by using qom-set QMP command.
Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com>
Reviewed-by: Tyrone Ting <kfting@nuvoton.com>
Signed-off-by: Hao Wu <wuhaotsh@google.com>
Message-id: 20210108190945.949196-4-wuhaotsh@google.com
[PMM: Added missing hw/adc/trace.h file]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch makes NPCM7XX Timer to use a the timer clock generated by the
CLK module instead of the magic number TIMER_REF_HZ.
Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com>
Reviewed-by: Tyrone Ting <kfting@nuvoton.com>
Signed-off-by: Hao Wu <wuhaotsh@google.com>
Message-id: 20210108190945.949196-3-wuhaotsh@google.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch allows NPCM7XX CLK module to compute clocks that are used by
other NPCM7XX modules.
Add a new struct NPCM7xxClockConverterState which represents a
single converter. Each clock converter in CLK module represents one
converter in NPCM7XX CLK Module(PLL, SEL or Divider). Each converter
takes one or more input clocks and converts them into one output clock.
They form a clock hierarchy in the CLK module and are responsible for
outputing clocks for various other modules in an NPCM7XX SoC.
Each converter has a function pointer called "convert" which represents
the unique logic for that converter.
The clock contains two initialization information: ConverterInitInfo and
ConverterConnectionInfo. They represent the vertices and edges in the
clock diagram respectively.
Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com>
Reviewed-by: Tyrone Ting <kfting@nuvoton.com>
Signed-off-by: Hao Wu <wuhaotsh@google.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20210108190945.949196-2-wuhaotsh@google.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The lan9118 code mostly uses symbolic constants for register offsets;
the exceptions are those which the datasheet doesn't give an official
symbolic name to.
Add some names for the registers which don't already have them, based
on the longer names they are given in the memory map.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20210108180401.2263-3-peter.maydell@linaro.org
In commit cd8be50e58 we converted the A32 coprocessor
insns to decodetree. This accidentally broke XScale/iWMMXt insns,
because it moved the handling of "cp insns which are handled
by looking up the cp register in the hashtable" from after the
call to the legacy disas_xscale_insn() decode to before it,
with the result that all XScale/iWMMXt insns now UNDEF.
Update valid_cp() so that it knows that on XScale cp 0 and 1
are not standard coprocessor instructions; this will cause
the decodetree trans_ functions to ignore them, so that
execution will correctly get through to the legacy decode again.
Cc: qemu-stable@nongnu.org
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-id: 20210108195157.32067-1-peter.maydell@linaro.org
In commit 1982e1602d we added a new qemu-storage-daemon(1) manpage.
At the moment new manpages have to be listed both in the conf.py for
Sphinx and also in docs/meson.build for Meson. We forgot the second
of those -- correct the omission.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20210108161416.21129-2-peter.maydell@linaro.org
QEMU documentation can't be opened if QEMU is run from build tree
because executables are placed in the top of build tree after conversion
to meson.
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20210108213815.64678-1-r.bolshakov@yadro.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When FEAT_MTE is implemented, the AArch64 view of CTR_EL0 adds the
TminLine field in bits [37:32].
Extend the ctr field to be able to hold this context.
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Hao Wu <wuhaotsh@google.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Laurent Desnogues <laurent.desnogues@gmail.com>
Message-id: 20210108185154.8108-4-leif@nuviainc.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The AArch64 view of CLIDR_EL1 extends the ICB field to include also bit
32, as well as adding a Ttype<n> field when FEAT_MTE is implemented.
Extend the clidr field to be able to hold this context.
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Laurent Desnogues <laurent.desnogues@gmail.com>
Message-id: 20210108185154.8108-3-leif@nuviainc.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This adds for the Small Translation tables extension in AArch64 state.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Prior to this patch, the fuzzer found inputs to map PCI device BARs and
enable the device. While it is nice that the fuzzer can do this, it
added significant overhead, since the fuzzer needs to map all the
BARs (regenerating the memory topology), at the start of each input.
With this patch, we do this once, before fuzzing, mitigating some of
this overhead.
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20201221181203.1853-1-alxndr@bu.edu>
Signed-off-by: Thomas Huth <thuth@redhat.com>
There was a race condition in the first test where there was already the
"crw" output in the dmesg, but the "0.0.4711" entry has not been created
in the /sys fs yet. Fix it by waiting until it is there.
The second test has even more problems on gitlab-CI. Even after adding some
more synchronization points (that wait for some messages in the "dmesg"
output to make sure that the modules got loaded correctly), there are still
occasionally some hangs in this test when it is running in the gitlab-CI.
So far I was unable to reproduce these hangs locally on my computer, so
this issue might take a while to debug. Thus disable the 2nd test in the
gitlab-CI until the problems are better understood and fixed.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Tested-by: Willian Rampazzo <willianr@redhat.com>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Message-Id: <20210108185645.86351-1-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Update strace.list to include all of FreeBSD's syscalls up through svn
r331280.
Signed-off-by: Stacey Son <sson@FreeBSD.org>
Signed-off-by: Sean Bruno <sburno@FreeBSD.org>
Signed-off-by: Alexander Kabaev <kan@FreeBSD.org>
Signed-off-by: Jung-uk Kim <jkim@FreeBSD.org>
Author: Michal Meloun <mmel@FreeBSD.org>
Signed-off-by: Mikaël Urankar <mikael.urankar@gmail.com>
[imp moved this change to early in the sequence]
Signed-off-by: Warner Losh <imp@FreeBSD.org>
Message-Id: <20201218205451.10559-5-imp@freebsd.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
This change moves host OS and arch dependent code for the sysarch
system call related to the -strace functionality into the
appropriate host OS and target arch directories.
Signed-off-by: Stacey Son <sson@FreeBSD.org>
Signed-off-by: Sean Bruno <sburno@FreeBSD.org>
[ imp integrated minor build fixes from sbruno ]
Signed-off-by: Warner Losh <imp@FreeBSD.org>
Message-Id: <20201218205451.10559-4-imp@freebsd.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Recreate the FreeBSD system call numbers from current sys/syscall.h. Since this
isn't guaranteed to be on all systems, continue the practice of generating it
with some variation on:
sed -e s/SYS_/TARGET_NR_/ < $FREEBSD_SRC/sys/syscall.h > syscall_nr.h
until a more comprehensive system can be put in place.
Signed-off-by: Warner Losh <imp@FreeBSD.org>
Message-Id: <20201218205451.10559-2-imp@freebsd.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
If previous write commands write the same length of data with the same step,
we view it as a hint.
Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com>
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Message-Id: <SYCPR01MB3502480AD07811A6A49B8FEAFCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
-M1: remove IO commands iteratively
-M2: try setting bits in operand of write/out to zero
Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com>
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Message-Id: <SYCPR01MB350204C52E7A39E6B0EEC870FCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Simplifying the crash cases by opportunistically setting bits in operands of
out/write to zero may help to debug, since usually bit one means turn on or
trigger a function while zero is the default turn-off setting.
Tested bug https://bugs.launchpad.net/qemu/+bug/1908062
Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com>
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Message-Id: <SYCPR01MB3502C84B6346A3E3DE708C7BFCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Now we use a one-time scan and remove strategy in the minimizer,
which is not suitable for timing dependent instructions.
For example, instruction A will indicate an address where the config
chunk locates, and instruction B will make the configuration active.
If we have the following instruction sequence:
...
A1
B1
A2
B2
...
A2 and B2 are the actual instructions that trigger the bug.
If we scan from top to bottom, after we remove A1, the behavior of B1
might be unknowable, including not to crash the program. But we will
successfully remove B1 later cause A2 and B2 will crash the process
anyway:
...
A1
A2
B2
...
Now one more trimming will remove A1.
In the perfect case, we would need to be able to remove A and B (or C!) at
the same time. But for now, let's just add a loop around the minimizer.
Since we only remove instructions, this iterative algorithm is converging.
Tested with Bug 1908062.
Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com>
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Message-Id: <SYCPR01MB350263004448040ACCB9A9F1FCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Currently, we split the write commands' data from the middle. If it does not
work, try to move the pivot left by one byte and retry until there is no
space.
But, this method has two flaws:
1. It may fail to trim all unnecessary bytes on the right side.
For example, there is an IO write command:
write addr uuxxxxuu
u is the unnecessary byte for the crash. Unlike ram write commands, in most
case, a split IO write won't trigger the same crash, So if we split from the
middle, we will get:
write addr uu (will be removed in next round)
write addr xxxxuu
For xxxxuu, since split it from the middle and retry to the leftmost byte
won't get the same crash, we will be stopped from removing the last two
bytes.
2. The algorithm complexity is O(n) since we move the pivot byte by byte.
To solve the first issue, we can try a symmetrical position on the right if
we fail on the left. As for the second issue, instead moving by one byte, we
can approach the boundary exponentially, achieving O(log(n)).
Give an example:
xxxxuu len=6
+
|
+
xxx,xuu 6/2=3 fail
+
+--------------+-------------+
| |
+ +
xx,xxuu 6/2^2=1 fail xxxxu,u 6-1=5 success
+ +
+------------------+----+ |
| | +-------------+ u removed
+ +
xx,xxu 5/2=2 fail xxxx,u 6-2=4 success
+
|
+-----------+ u removed
In some rare cases, this algorithm will fail to trim all unnecessary bytes:
xxxxxxxxxuxxxxxx
xxxxxxxx-xuxxxxxx Fail
xxxx-xxxxxuxxxxxx Fail
xxxxxxxxxuxx-xxxx Fail
...
I think the trade-off is worth it.
Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com>
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Message-Id: <SYCPR01MB3502D26F1BEB680CBBC169E5FCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Instead of removing IO instructions one by one, we can try deleting multiple
instructions at once. According to the locality of reference, we double the
number of instructions to remove for the next round and recover it to one
once we fail.
This patch is usually significant for large input.
Test with quadrupled trace input at:
https://bugs.launchpad.net/qemu/+bug/1890333/comments/1
Patched 1/6 version:
real 0m45.904s
user 0m16.874s
sys 0m10.042s
Refined version:
real 0m11.412s
user 0m6.888s
sys 0m3.325s
Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com>
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Message-Id: <SYCPR01MB350280A67BB55C3FADF173E3FCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
We spend much time waiting for the timeout program during the minimization
process until it passes a time limit. This patch hacks the CLOSED (indicates
the redirection file closed) notification in QTest's output if it doesn't
crash.
Test with quadrupled trace input at:
https://bugs.launchpad.net/qemu/+bug/1890333/comments/1
Original version:
real 1m37.246s
user 0m13.069s
sys 0m8.399s
Refined version:
real 0m45.904s
user 0m16.874s
sys 0m10.042s
Note:
Sometimes the mutated or the same trace may trigger a different crash
summary (second-to-last line) but indicates the same bug. For example, Bug
1910826 [1], which will trigger a stack overflow, may output summaries
like:
SUMMARY: AddressSanitizer: stack-overflow
/home/qiuhao/hack/qemu/build/../softmmu/physmem.c:488 in
flatview_do_translate
or
SUMMARY: AddressSanitizer: stack-overflow
(/home/qiuhao/hack/qemu/build/qemu-system-i386+0x27ca049) in __asan_memcpy
Etc.
If we use the whole summary line as the token, we may be prevented from
further minimization. So in this patch, we only use the first three words
which indicate the type of crash:
SUMMARY: AddressSanitizer: stack-overflow
[1] https://bugs.launchpad.net/qemu/+bug/1910826
Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com>
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Message-Id: <SYCPR01MB350251DC04003450348FAF68FCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
When the length of mname is less than 5, memcpy("xenfv", mname, 5) will cause
heap buffer overflow. Therefore, use strncmp to avoid this problem.
The asan showed stack:
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000f2f4 at
pc 0x7f65d8cc2225 bp 0x7ffe93cc5a60 sp 0x7ffe93cc5208 READ of size 5 at
0x60200000f2f4 thread T0
#0 0x7f65d8cc2224 in memcmp (/lib64/libasan.so.5+0xdf224)
#1 0x5632c20be95b in qtest_cb_for_every_machine tests/qtest/libqtest.c:1282
#2 0x5632c20b7995 in main tests/qtest/test-hmp.c:160
#3 0x7f65d88fed42 in __libc_start_main (/lib64/libc.so.6+0x26d42)
#4 0x5632c20b72cd in _start (build/tests/qtest/test-hmp+0x542cd)
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Message-Id: <20210106050625.518041-1-ganqixin@huawei.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Add build-system-opensuse jobs and opensuse-leap.docker dockerfile.
Use openSUSE Leap 15.2 container image in the gitlab-CI.
Signed-off-by: Cho, Yu-Chen <acho@suse.com>
Tested-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Message-Id: <20201229085046.8536-1-acho@suse.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
* intc/arm_gic: Fix gic_irq_signaling_enabled() for vCPUs
* target/arm: Fix MTE0_ACTIVE
* target/arm: Implement v8.1M and Cortex-M55 model
* hw/arm/highbank: Drop dead KVM support code
* util/qemu-timer: Make timer_free() imply timer_del()
* various devices: Use ptimer_free() in finalize function
* docs/system: arm: Add sabrelite board description
* sabrelite: Minor fixes to allow booting U-Boot
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAl/4e4EZHHBldGVyLm1h
eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3gMyEACEw5WokZvu14sZqgoPX+he
lgnzwMcorCdcWZ5ohU7jU37Us5MVbdH5/7rn8VLX1BeRxxqPexTfuxqZVhbzfFCI
S4AfH/P9KRrRWaGXyhCdQfCl2Re4YqRw2cTFUnh0hq15rwWLVYNGm4cawahJQcPT
hu3AC3TSebGi+LRVpI/gkFy5h9NQOM2Y19TKttjxE1VZSzJtPvzGQ4srXMRURjSP
9w2bMBgabLLeawFq8z/wsJR7N5th/+w2x4x0Os6vSq68ZNmLNa0eralNrFf9V02g
iyAIGBMyhaDIAtTouhS44UDF+m/kLGyMAfrIj1C0ODN+DociYYwqsI4QDCqexuz4
WvIlMRSHIhKowuQ9KE6zI3bQEONjdL+IvgwyltEtsWq40DH0hVqaDmb/IlNj6nwd
MPGH+paCK4dhpBQt6wFtHrb+0RjiHdMkbPXivJozkJfdmgUeXyFsRChoYwXGE9la
JO6jHMP0dGL7N5OMloEu1GGyvHjROhvYftBZNgWUCUte7nhzADoTvKVDs4Fl9UiI
UljRaizjoOPrRhi39Q+I1JT7OZbsXjcwGkj2PNRdYnqRRze6iA6zR+b7ZP/6SS7s
wiV8vKQxHIMIfkLLpxB45epIXVITDrvFPzOGrfV4ByUQT5Ay1zbTrAzg7GPoWU2h
D91R3A/XSPSIxu3CiINENg==
=a4lf
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20210108' into staging
target-arm queue:
* intc/arm_gic: Fix gic_irq_signaling_enabled() for vCPUs
* target/arm: Fix MTE0_ACTIVE
* target/arm: Implement v8.1M and Cortex-M55 model
* hw/arm/highbank: Drop dead KVM support code
* util/qemu-timer: Make timer_free() imply timer_del()
* various devices: Use ptimer_free() in finalize function
* docs/system: arm: Add sabrelite board description
* sabrelite: Minor fixes to allow booting U-Boot
# gpg: Signature made Fri 08 Jan 2021 15:34:25 GMT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* remotes/pmaydell/tags/pull-target-arm-20210108: (23 commits)
docs/system: arm: Add sabrelite board description
hw/arm: sabrelite: Connect the Ethernet PHY at address 6
hw/msic: imx6_ccm: Correct register value for silicon type
hw/misc: imx6_ccm: Update PMU_MISC0 reset value
exynos4210_mct: Use ptimer_free() in the finalize function to avoid memleaks
musicpal: Use ptimer_free() in the finalize function to avoid memleaks
mss-timer: Use ptimer_free() in the finalize function to avoid memleaks
exynos4210_pwm: Use ptimer_free() in the finalize function to avoid memleaks
exynos4210_rtc: Use ptimer_free() in the finalize function to avoid memleaks
allwinner-a10-pit: Use ptimer_free() in the finalize function to avoid memleaks
digic-timer: Use ptimer_free() in the finalize function to avoid memleaks
target/arm: Remove timer_del()/timer_deinit() before timer_free()
Remove superfluous timer_del() calls
scripts/coccinelle: New script to remove unnecessary timer_del() calls
util/qemu-timer: Make timer_free() imply timer_del()
hw/arm/highbank: Drop dead KVM support code
target/arm: Implement Cortex-M55 model
target/arm: Implement FPCXT_NS fp system register
target/arm: Correct store of FPSCR value via FPCXT_S
hw/intc/armv7m_nvic: Correct handling of CCR.BFHFNMIGN
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This adds the target guide for SABRE Lite board, and documents how
to boot a Linux kernel and U-Boot bootloader.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20210106063504.10841-5-bmeng.cn@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
At present, when booting U-Boot on QEMU sabrelite, we see:
Net: Board Net Initialization Failed
No ethernet found.
U-Boot scans PHY at address 4/5/6/7 (see board_eth_init() in the
U-Boot source: board/boundary/nitrogen6x/nitrogen6x.c). On the real
board, the Ethernet PHY is at address 6. Adjust this by updating the
"fec-phy-num" property of the fsl_imx6 SoC object.
With this change, U-Boot sees the PHY but complains MAC address:
Net: using phy at 6
FEC [PRIME]
Error: FEC address not set.
This is due to U-Boot tries to read the MAC address from the fuse,
which QEMU does not have any valid content filled in. However this
does not prevent the Ethernet from working in QEMU. We just need to
set up the MAC address later in the U-Boot command shell, by:
=> setenv ethaddr 00:11:22:33:44:55
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20210106063504.10841-4-bmeng.cn@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Currently when U-Boot boots, it prints "??" for i.MX processor:
CPU: Freescale i.MX?? rev1.0 at 792 MHz
The register that was used to determine the silicon type is
undocumented in the latest IMX6DQRM (Rev. 6, 05/2020), but we
can refer to get_cpu_rev() in arch/arm/mach-imx/mx6/soc.c in
the U-Boot source codes that USB_ANALOG_DIGPROG is used.
Update its reset value to indicate i.MX6Q.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20210106063504.10841-3-bmeng.cn@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
U-Boot expects PMU_MISC0 register bit 7 is set (see init_bandgap()
in arch/arm/mach-imx/mx6/soc.c) during boot. This bit indicates the
bandgap has stabilized.
With this change, the latest upstream U-Boot (v2021.01-rc3) for imx6
sabrelite board (mx6qsabrelite_defconfig), with a slight change made
by switching CONFIG_OF_SEPARATE to CONFIG_OF_EMBED, boots to U-Boot
shell on QEMU with the following command:
$ qemu-system-arm -M sabrelite -smp 4 -m 1G -kernel u-boot \
-display none -serial null -serial stdio
Boot log below:
U-Boot 2021.01-rc3 (Dec 12 2020 - 17:40:02 +0800)
CPU: Freescale i.MX?? rev1.0 at 792 MHz
Reset cause: POR
Model: Freescale i.MX6 Quad SABRE Lite Board
Board: SABRE Lite
I2C: ready
DRAM: 1 GiB
force_idle_bus: sda=0 scl=0 sda.gp=0x5c scl.gp=0x55
force_idle_bus: failed to clear bus, sda=0 scl=0
force_idle_bus: sda=0 scl=0 sda.gp=0x6d scl.gp=0x6c
force_idle_bus: failed to clear bus, sda=0 scl=0
force_idle_bus: sda=0 scl=0 sda.gp=0xcb scl.gp=0x5
force_idle_bus: failed to clear bus, sda=0 scl=0
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - No block device, using default environment
In: serial
Out: serial
Err: serial
Net: Board Net Initialization Failed
No ethernet found.
starting USB...
Bus usb@2184000: usb dr_mode not found
USB EHCI 1.00
Bus usb@2184200: USB EHCI 1.00
scanning bus usb@2184000 for devices... 1 USB Device(s) found
scanning bus usb@2184200 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
Hit any key to stop autoboot: 0
=>
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20210106063504.10841-2-bmeng.cn@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the
exynos4210_mct_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 96 byte(s) in 1 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf56b01a0 in exynos4210_mct_init /qemu/hw/timer/exynos4210_mct.c:1505
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
#9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136
#10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164
#11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381
#12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the
mv88w8618_pit_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 192 byte(s) in 4 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523
#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544
#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562
#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433
#6 0xaaabf5bb2290 in mv88w8618_timer_init /qemu/hw/arm/musicpal.c:862
#7 0xaaabf5bb2290 in mv88w8618_pit_init /qemu/hw/arm/musicpal.c:954
#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#11 0xaaabf5a95540 in qdev_device_help /qemu/softmmu/qdev-monitor.c:283
#12 0xaaabf5a96940 in qmp_device_add /qemu/softmmu/qdev-monitor.c:801
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the
mss_timer_init function, so use ptimer_free() in the finalize function to avoid
it.
ASAN shows memory leak stack:
Indirect leak of 192 byte(s) in 2 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf58a0010 in mss_timer_init /qemu/hw/timer/mss-timer.c:235
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564
#6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547
#7 0xaaabf5b8316c in m2sxxx_soc_initfn /qemu/hw/arm/msf2-soc.c:70
#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the
exynos4210_pwm_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 240 byte(s) in 5 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523
#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544
#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562
#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433
#6 0xaaabf56a36cc in exynos4210_pwm_init /qemu/hw/timer/exynos4210_pwm.c:401
#7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#8 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#9 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#10 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#11 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
#12 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the
exynos4210_rtc_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 96 byte(s) in 1 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf57b3934 in exynos4210_rtc_init /qemu/hw/rtc/exynos4210_rtc.c:567
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
#9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136
#10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164
#11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381
#12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
