The SSE-300 has an ITCM at 0x0000_0000 and a DTCM at 0x2000_0000.
Currently we model these in the AN547 board, but this is conceptually
wrong, because they are a part of the SSE-300 itself. Move the
modelling of the TCMs out of mps2-tz.c into sse300.c.
This has no guest-visible effects.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210510190844.17799-7-peter.maydell@linaro.org
Currently we model the ITCM in the AN547's RAMInfo list. This is incorrect
because this RAM is really a part of the SSE-300. We can't just delete
it from the RAMInfo list, though, because this would make boot_ram_size()
assert because it wouldn't be able to find an entry in the list covering
guest address 0.
Allow a board to specify a boot RAM size manually if it doesn't have
any RAM itself at address 0 and is relying on the SSE for that, and
set the correct value for the AN547. The other boards can continue
to use the "look it up from the RAMInfo list" logic.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210510190844.17799-6-peter.maydell@linaro.org
Convert armsse_realize() to use ERRP_GUARD(), following
the rules in include/qapi/error.h.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210510190844.17799-5-peter.maydell@linaro.org
The SSE-300 was not correctly modelling its internal SRAMs:
* the SRAM address width default is 18
* the SRAM is mapped at 0x2100_0000, not 0x2000_0000 like
the SSE-200 and IoTKit
The default address width is no longer guest-visible since
our only SSE-300 board sets it explicitly to a non-default
value, but following the hardware's default will help for
any future boards we need to model.
Reported-by: Devaraj Ranganna <devaraj.ranganna@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210510190844.17799-4-peter.maydell@linaro.org
The AN547 sets the SRAM_ADDR_WIDTH for the SSE-300 to 21;
since this is not the default value for the SSE-300, model this
in mps2-tz.c as a per-board value.
Reported-by: Devaraj Ranganna <devaraj.ranganna@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210510190844.17799-3-peter.maydell@linaro.org
The SRAM at 0x2000_0000 is part of the SSE-200 itself, and we model
it that way in hw/arm/armsse.c (along with the associated MPCs). We
incorrectly also added an entry to the RAMInfo array for the AN524 in
hw/arm/mps2-tz.c, which was pointless because the CPU would never see
it. Delete it.
The bug had no guest-visible effect because devices in the SSE-200
take priority over those in the board model (armsse.c maps
s->board_memory at priority -2).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210510190844.17799-2-peter.maydell@linaro.org
In icc_eoir_write() we assume that we can identify the group of the
IRQ being completed based purely on which register is being written
to and the current CPU state, and that "CPU state matches group
indicated by register" is the only necessary access check.
This isn't correct: if the CPU is not in Secure state then EOIR1 will
only complete Group 1 NS IRQs, but if the CPU is in EL3 it can
complete both Group 1 S and Group 1 NS IRQs. (The pseudocode
ICC_EOIR1_EL1 makes this clear.) We were also missing the logic to
prevent EOIR0 writes completing G0 IRQs when they should not.
Rearrange the logic to first identify the group of the current
highest priority interrupt and then look at whether we should
complete it or ignore the access based on which register was accessed
and the state of the CPU. The resulting behavioural change is:
* EL3 can now complete G1NS interrupts
* G0 interrupt completion is now ignored if the GIC
and the CPU have the security extension enabled and
the CPU is not secure
Reported-by: Chan Kim <ckim@etri.re.kr>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210510150016.24910-1-peter.maydell@linaro.org
6d9cd115b9 ("hw/arm/smmuv3: Enforce invalidation on a power of two range")
failed to completely fix misalignment issues with range
invalidation. For instance invalidations patterns like "invalidate 32
4kB pages starting from 0xff395000 are not correctly handled" due
to the fact the previous fix only made sure the number of invalidated
pages were a power of 2 but did not properly handle the start
address was not aligned with the range. This can be noticed when
boothing a fedora 33 with protected virtio-blk-pci.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Fixes: 6d9cd115b9 ("hw/arm/smmuv3: Enforce invalidation on a power of two range")
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Allow using QemuCoSleep to sleep forever until woken by qemu_co_sleep_wake.
This makes the logic of qemu_co_sleep_ns_wakeable easy to understand.
In the future we will introduce an API that can work even if the
sleep and wake happen from different threads. For now, initializing
w->to_wake after timer_mod is fine because the timer can only fire in
the same AioContext.
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20210517100548.28806-7-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Right now, users of qemu_co_sleep_ns_wakeable are simply passing
a pointer to QemuCoSleepState by reference to the function. But
QemuCoSleepState really is just a Coroutine*; making the
content of the struct public is just as efficient and lets us
skip the user_state_pointer indirection.
Since the usage is changed, take the occasion to rename the
struct to QemuCoSleep.
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20210517100548.28806-6-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This simplification is enabled by the previous patch. Now aio_co_wake
will only be called once, therefore we do not care about a spurious
firing of the timer after a qemu_co_sleep_wake.
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20210517100548.28806-5-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
All callers of qemu_co_sleep_wake are checking whether they are passing
a NULL argument inside the pointer-to-pointer: do the check in
qemu_co_sleep_wake itself.
As a side effect, qemu_co_sleep_wake can be called more than once and
it will only wake the coroutine once; after the first time, the argument
will be set to NULL via *sleep_state->user_state_pointer. However, this
would not be safe unless co_sleep_cb keeps using the QemuCoSleepState*
directly, so make it go through the pointer-to-pointer instead.
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20210517100548.28806-4-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Simplify the code by removing conditionals. qemu_co_sleep_ns
can simply point the argument to an on-stack temporary.
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20210517100548.28806-3-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The lifetime of the timer is well-known (it cannot outlive
qemu_co_sleep_ns_wakeable, because it's deleted by the time the
coroutine resumes), so it is not necessary to place it on the heap.
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20210517100548.28806-2-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Document the following functions return the bitmap size
if no matching bit is found:
- find_first_bit
- find_next_bit
- find_last_bit
- find_first_zero_bit
- find_next_zero_bit
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20210510200758.2623154-2-philmd@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Quote docs/devel/style.rst (section "Automatic memory deallocation"):
* Variables declared with g_auto* MUST always be initialized,
otherwise the cleanup function will use uninitialized stack memory
Initialize @name properly to get rid of the compilation error (using
gcc-7.3.0 on CentOS):
../hw/remote/proxy.c: In function 'pci_proxy_dev_realize':
/usr/include/glib-2.0/glib/glib-autocleanups.h:28:3: error: 'name' may be used uninitialized in this function [-Werror=maybe-uninitialized]
g_free (*pp);
^~~~~~~~~~~~
../hw/remote/proxy.c:350:30: note: 'name' was declared here
g_autofree char *name;
^~~~
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Reviewed-by: Jagannathan Raman <jag.raman@oracle.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Miroslav Rezanina <mrezanin@redhat.com>
Message-id: 20210312112143.1369-1-yuzenghui@huawei.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Want place gtk clipboard code in a separate C file, which in turn
requires GtkDisplayState being in a header file. So move it. No
functional change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20210519053940.1888907-1-kraxel@redhat.com
Message-Id: <20210519053940.1888907-9-kraxel@redhat.com>
This patch adds support for cut+paste to the qemu vnc server, which
allows the vnc client exchange clipbaord data with qemu and other peers
like the qemu vdagent implementation.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20210519053940.1888907-1-kraxel@redhat.com
Message-Id: <20210519053940.1888907-8-kraxel@redhat.com>
This patch adds support for clipboard messages to the qemu vdagent
implementation, which allows the guest exchange clipboard data with
qemu. Clipboard support can be enabled/disabled using the new
'clipboard' parameter for the vdagent chardev. Default is off.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20210519053940.1888907-1-kraxel@redhat.com
Message-Id: <20210519053940.1888907-7-kraxel@redhat.com>
This patch adds support for mouse messages to the vdagent
implementation. This can be enabled/disabled using the new
'mouse' parameter for the vdagent chardev. Default is on.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-id: 20210519053940.1888907-1-kraxel@redhat.com
Message-Id: <20210519053940.1888907-6-kraxel@redhat.com>
The vdagent protocol allows the guest agent (spice-vdagent) and the
spice client exchange messages to implement features which require
guest cooperation, for example clipboard support.
This is a qemu implementation of the spice client side. This allows
the spice guest agent talk to qemu directly when not using the spice
protocol.
usage: qemu \
-chardev qemu-vdagent,id=vdagent \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0
This patch adds just the protocol basics: initial handshake and
capability negotiation. The following patches will add actual
functionality and also add fields to the initially empty
ChardevVDAgent qapi struct.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20210519053940.1888907-1-kraxel@redhat.com
Message-Id: <20210519053940.1888907-5-kraxel@redhat.com>
When implementing spice vdagent protocol in qemu we only need the
spice-protocol package for that, spice-server is not needed. So
go split those two build dependencies.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20210519053940.1888907-1-kraxel@redhat.com
Message-Id: <20210519053940.1888907-2-kraxel@redhat.com>
Xtensa cores may or may not have hardware support for unaligned memory
access. Remove TARGET_ALIGNED_ONLY=y from all xtensa configurations and
pass MO_ALIGN in memory access flags for all operations that would raise
an exception.
Simplify use of gen_load_store_alignment by passing access size and
alignment requirements in single parameter.
Drop condition from xtensa_cpu_do_unaligned_access and replace it with
assertion.
Add a test.
Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
l32ex does memory access as all regular load/store operations at CRING
level. Fix apparent pasto from l32e that caused it to use RING instead.
This is a correctness issue, not a security issue, because in the worst
case the privilege level of memory access may be lowered, resulting in
an exception when the correct implementation would've succeeded.
In no case it would allow memory access that would've raised an
exception in the correct implementation.
Cc: qemu-stable@nongnu.org
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
target/xtensa used to generate an extra EXCP_DEBUG exception before the
first instruction executed after an interrupt or an exception is taken
to allow single-stepping that instruction in the debugger.
This is no longer needed after the following commits:
a7ba744f40 ("tcg/cpu-exec: precise single-stepping after an exception")
ba3c35d9c4 ("tcg/cpu-exec: precise single-stepping after an interrupt")
Drop exception state tracking/extra EXCP_DEBUG generation code.
Cc: qemu-stable@nongnu.org # v5.1, v5.2, v6.0
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
We can have a two-letter variable name, as a treat.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-Id: <20210519183951.3946870-15-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
bsd-user fork into qemu. It contains a number of style commits, as well as 3
commits that start to change things: Some unused files are deleted, building the
sparc and sparc64 targets are removed, and a structure is renamed.
The next set of pull requests will start to execute the following plan:
1. Move existing code around to have a structure similar to the bsd-user fork.
2. Incrementally merge groups of system calls, focused on making x86 work.
3. Once the groups of system calls are all merged, additional platforms will
be added back.
4. Concurrently, as changes are requested as part of the merge happen, those
changes will be merged into the fork. An experimental merge to tip of master
is under test and is what will be updated.
5. Eventually, there will be no diference, and the bsd-user fork will only
be a staging area for cutting-edge features prior to upstreaming into
qemu mainline.
The bsd-user code in qemu has a lot of style issues. This cleans up a number in
the files touched. However, the checkpatch.pl detects some incremental issues in
the commits. The following are expected, but are corrected in later hashes in
this branch. MAINTAINERS does not need to be updated, since all the files added
or deleted are covered under existing regexp in MAINTAINERS.
Checking all commits since f9a576a818044133f8564e0d243ebd97df0b3280...
d60c3b932e2fa06aba5d7aa1c451b5d287095dc8:101: ERROR: consider using qemu_strtol in preference to strtol
d60c3b932e2fa06aba5d7aa1c451b5d287095dc8:142: ERROR: braces {} are necessary for all arms of this statement
d60c3b932e2fa06aba5d7aa1c451b5d287095dc8:145: ERROR: braces {} are necessary for all arms of this statement
total: 3 errors, 0 warnings, 119 lines checked
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:148: WARNING: line over 80 characters
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:330: ERROR: braces {} are necessary for all arms of this statement
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:340: ERROR: braces {} are necessary for all arms of this statement
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:381: ERROR: space prohibited between function name and open parenthesis '('
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:390: ERROR: spaces required around that '<' (ctx:VxV)
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:408: WARNING: Block comments use a leading /* on a separate line
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:409: WARNING: Block comments use * on subsequent lines
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:409: WARNING: Block comments use a trailing */ on a separate line
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:441: WARNING: line over 80 characters
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:445: WARNING: line over 80 characters
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:502: ERROR: line over 90 characters
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:551: ERROR: space required after that ',' (ctx:VxV)
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:552: ERROR: space required after that ',' (ctx:VxV)
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:587: ERROR: space required after that ';' (ctx:VxV)
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:623: ERROR: suspect code indent for conditional statements (12, 14)
total: 9 errors, 6 warnings, 664 lines checked
86545e7afe3f822b8561c7ceee7540fc3b19c3f0:31: ERROR: space required after that ';' (ctx:VxV)
86545e7afe3f822b8561c7ceee7540fc3b19c3f0:40: ERROR: space required after that ';' (ctx:VxV)
total: 2 errors, 0 warnings, 60 lines checked
Use of uninitialized value $acpi_testexpected in string eq at scripts/checkpatch.pl line 1529.
65d58c91ef1a15ad945ece367983437576f8e82b:22: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
total: 0 errors, 1 warnings, 14 lines checked
Use of uninitialized value $acpi_testexpected in string eq at scripts/checkpatch.pl line 1529.
f8ce39701b5be032fb3f9c05e8adb4055f70eec2:21: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
total: 0 errors, 1 warnings, 0 lines checked
FAIL one or more commits failed scripts/checkpatch.pl
Cleaning up file based variables
ERROR: Job failed: exit code 1
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIzBAABCgAdFiEEIDX4lLAKo898zeG3bBzRKH2wEQAFAmCcBQIACgkQbBzRKH2w
EQD4+A/9E3Yr7cIBegz0km6pTHX89y6AW4+qd6QkQgYkZ9PloIVCjSn3NxvvPy3d
sCVhZu2FutEuoI2EOjzBpgQCp8mhSfayPKiZIzvHeJn9yiTmNnuHd/Opr2NaxkUV
WT9Eli7aB5AhYL1AD6RVEyYQYQJLq/ULdJXUVaOe5X2werk/FT7izhVqA4hkMFUm
Rx3RrMZDAyhgPT1+EUrNMgw2/dQw7QEH3w0RREc/Btfs8Wwisqq+Uy0Z8p9+khSU
K5ES6FnYAoOU9EP1LMjOzuh54B2Ta9J0Z4vfjlul8+WM9DBap5FogiNChVd/mjvL
1NYJUPFIC9KaV+5xNAJanW7h531lFKwHzZka68Dmzsbjdj0sUg2GkPhneOXEH8lX
Q6Kmoxpg8IpfwfB/VDPM4eL3SdNQd8d/1VSUkLOS0reOc8L9RmLXSYlJILzNkDR9
yODoBgSktX2e4wnyuknyXi1JuIx2yHCsPHq+PtBYUnHEfc8W7V9yxwhAYshuRQDy
sZO1AdwEQHzgNjnCPK8ru6DqrizHwKnlE1KUy5KxUOcmfaacZ//t9ezf8qSd19eC
6deGfmfvp3Xxtz38eCLogKJXzIDjf+FMaN+0znOd0ut9qPPCqBgALZNnkeaDz+zx
2ZGhjwcRAsKZmGSLQoKPN+YkM5POwzWvEPNApPsVJjpTXpoZcJ8=
=pW6n
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/bsdimp/tags/pull-bsd-user-20210511' into staging
pull-bsd-user-20210511 is the next round of cleanups to bsd-user in merging the
bsd-user fork into qemu. It contains a number of style commits, as well as 3
commits that start to change things: Some unused files are deleted, building the
sparc and sparc64 targets are removed, and a structure is renamed.
The next set of pull requests will start to execute the following plan:
1. Move existing code around to have a structure similar to the bsd-user fork.
2. Incrementally merge groups of system calls, focused on making x86 work.
3. Once the groups of system calls are all merged, additional platforms will
be added back.
4. Concurrently, as changes are requested as part of the merge happen, those
changes will be merged into the fork. An experimental merge to tip of master
is under test and is what will be updated.
5. Eventually, there will be no diference, and the bsd-user fork will only
be a staging area for cutting-edge features prior to upstreaming into
qemu mainline.
The bsd-user code in qemu has a lot of style issues. This cleans up a number in
the files touched. However, the checkpatch.pl detects some incremental issues in
the commits. The following are expected, but are corrected in later hashes in
this branch. MAINTAINERS does not need to be updated, since all the files added
or deleted are covered under existing regexp in MAINTAINERS.
Checking all commits since f9a576a818044133f8564e0d243ebd97df0b3280...
d60c3b932e2fa06aba5d7aa1c451b5d287095dc8:101: ERROR: consider using qemu_strtol in preference to strtol
d60c3b932e2fa06aba5d7aa1c451b5d287095dc8:142: ERROR: braces {} are necessary for all arms of this statement
d60c3b932e2fa06aba5d7aa1c451b5d287095dc8:145: ERROR: braces {} are necessary for all arms of this statement
total: 3 errors, 0 warnings, 119 lines checked
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:148: WARNING: line over 80 characters
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:330: ERROR: braces {} are necessary for all arms of this statement
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:340: ERROR: braces {} are necessary for all arms of this statement
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:381: ERROR: space prohibited between function name and open parenthesis '('
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:390: ERROR: spaces required around that '<' (ctx:VxV)
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:408: WARNING: Block comments use a leading /* on a separate line
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:409: WARNING: Block comments use * on subsequent lines
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:409: WARNING: Block comments use a trailing */ on a separate line
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:441: WARNING: line over 80 characters
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:445: WARNING: line over 80 characters
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:502: ERROR: line over 90 characters
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:551: ERROR: space required after that ',' (ctx:VxV)
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:552: ERROR: space required after that ',' (ctx:VxV)
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:587: ERROR: space required after that ';' (ctx:VxV)
b4bebeee1dee8d333bfa105a6c28fec5eb34b147:623: ERROR: suspect code indent for conditional statements (12, 14)
total: 9 errors, 6 warnings, 664 lines checked
86545e7afe3f822b8561c7ceee7540fc3b19c3f0:31: ERROR: space required after that ';' (ctx:VxV)
86545e7afe3f822b8561c7ceee7540fc3b19c3f0:40: ERROR: space required after that ';' (ctx:VxV)
total: 2 errors, 0 warnings, 60 lines checked
Use of uninitialized value $acpi_testexpected in string eq at scripts/checkpatch.pl line 1529.
65d58c91ef1a15ad945ece367983437576f8e82b:22: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
total: 0 errors, 1 warnings, 14 lines checked
Use of uninitialized value $acpi_testexpected in string eq at scripts/checkpatch.pl line 1529.
f8ce39701b5be032fb3f9c05e8adb4055f70eec2:21: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
total: 0 errors, 1 warnings, 0 lines checked
FAIL one or more commits failed scripts/checkpatch.pl
Cleaning up file based variables
ERROR: Job failed: exit code 1
# gpg: Signature made Wed 12 May 2021 17:40:34 BST
# gpg: using RSA key 2035F894B00AA3CF7CCDE1B76C1CD1287DB01100
# gpg: Good signature from "Warner Losh <wlosh@netflix.com>" [unknown]
# gpg: aka "Warner Losh <imp@bsdimp.com>" [unknown]
# gpg: aka "Warner Losh <imp@freebsd.org>" [unknown]
# gpg: aka "Warner Losh <imp@village.org>" [unknown]
# gpg: aka "Warner Losh <wlosh@bsdimp.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: 2035 F894 B00A A3CF 7CCD E1B7 6C1C D128 7DB0 1100
* remotes/bsdimp/tags/pull-bsd-user-20210511:
bsd-user: rename linux_binprm to bsd_binprm
bsd-user: Stop building the sparc targets
bsd-user: remove target_signal.h, it's unused
bsd-user: style tweak: keyword space (
bsd-user: style tweak: Remove #if 0'd code
bsd-user: style tweak: keyword space (
bsd-user: style tweak: keyword space (
bsd-user: whitespace changes
bsd-user: use qemu_strtoul in preference to strtol
bsd-user: style tweak: use {} consistently in for / if / else statements
bsd-user: style tweak: use {} for all if statements, format else correctly
bsd-user: style tweak: don't assign in if statements
bsd-user: style tweak: Use preferred block comments
bsd-user: style tweak: remove spacing after '*' and add after }
bsd-user: style tweak: move extern to header file
bsd-user: Remove commented out code
bsd-user: style tweak: Use preferred block comments
bsd-user: style tweak: Remove #if 0'd code
bsd-user: style tweak: use C not C++ comments
bsd-user: whitespace changes
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Having a small test will prevent trivial regressions in the future.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-Id: <20210519045738.1335210-3-iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
tb_gen_code() assumes that tb->size must never be zero, otherwise it
may produce spurious exceptions. For x86_64 this may happen when
creating a translation block for the vsyscall page.
Fix by pretending that vsyscall translation blocks have at least one
instruction.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20210519045738.1335210-2-iii@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
The vfio_ccw_unrealize() routine makes an unconditional attempt to
unregister every IRQ notifier, though they may not have been registered
in the first place (when running on an older kernel, for example).
Let's mirror this behavior in the error cleanups in vfio_ccw_realize()
so that if/when new IRQs are added, it is less confusing to recognize
the necessary procedures. The worst case scenario would be some extra
messages about an undefined IRQ, but since this is an error exit that
won't be the only thing to worry about.
And regarding those messages, let's change it to a warning instead of
an error, to better reflect their severity. The existing code in both
paths handles everything anyway.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Acked-by: Matthew Rosato <mjrosato@linux.ibm.com>
Message-Id: <20210428143652.1571487-1-farman@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Instead of having all TYPE_CCW_DEVICE children set the bus type to
TYPE_VIRTUAL_CSS_BUS, do it once in the abstract parent.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Acked-by: Eric Farman <farman@linux.ibm.com>
Message-Id: <20210424145313.3287400-1-f4bug@amsat.org>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Commit 690e29b911 ("vfio-ccw: Refactor ccw irq handler") changed
one of the checks for the IRQ notifier registration from saying
"the host needs to recognize the only IRQ that exists" to saying
"the host needs to recognize ANY IRQ that exists."
And this worked fine, because the subsequent change to support the
CRW IRQ notifier doesn't get into this code when running on an older
kernel, thanks to a guard by a capability region. The later addition
of the REQ(uest) IRQ by commit b2f96f9e4f ("vfio-ccw: Connect the
device request notifier") broke this assumption because there is no
matching capability region. Thus, running new QEMU on an older
kernel fails with:
vfio: unexpected number of irqs 2
Let's adapt the message here so that there's a better clue of what
IRQ is missing.
Furthermore, let's make the REQ(uest) IRQ not fail when attempting
to register it, to permit running vfio-ccw on a newer QEMU with an
older kernel.
Fixes: b2f96f9e4f ("vfio-ccw: Connect the device request notifier")
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Message-Id: <20210421152053.2379873-1-farman@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
If arch-specific code generates a translation block of size 0,
tb_gen_code() may generate a spurious exception. Add an assertion in
order to catch such situations early.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <20210416154939.32404-5-iii@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
tb_gen_code() assumes that tb->size must never be zero, otherwise it
may produce spurious exceptions. For xtensa this may happen when
decoding an unknown instruction, when handling a write into the
CCOUNT or CCOMPARE special register and when single-stepping the first
instruction of an exception handler.
Fix by pretending that the size of the respective translation block is
1 in all these cases.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Tested-by: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>
Message-Id: <20210416154939.32404-4-iii@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
tb_gen_code() assumes that tb->size must never be zero, otherwise it
may produce spurious exceptions. For ARM this may happen when creating
a translation block for the commpage.
Fix by pretending that commpage translation blocks have at least one
instruction.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20210416154939.32404-3-iii@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Hitting an uretprobe in a s390x TCG guest causes a SIGSEGV. What
happens is:
* uretprobe maps a userspace page containing an invalid instruction.
* uretprobe replaces the target function's return address with the
address of that page.
* When tb_gen_code() is called on that page, tb->size ends up being 0
(because the page starts with the invalid instruction), which causes
virt_page2 to point to the previous page.
* The previous page is not mapped, so this causes a spurious
translation exception.
tb->size must never be 0: even if there is an illegal instruction, the
instruction bytes that have been looked at must count towards tb->size.
So adjust s390x's translate_one() to act this way for both illegal
instructions and instructions that are known to generate exceptions.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <20210416154939.32404-2-iii@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
