OSDN Git Service
Michael Roth [Tue, 27 Oct 2020 06:02:53 +0000 (01:02 -0500)]
MAINTAINERS: update my email address
I've recently switched employers and the current email address is out
of date.
Signed-off-by: Michael Roth <michael.roth@amd.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <
20201027060253.353054-1-michael.roth@amd.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Peter Maydell [Sat, 21 Nov 2020 21:35:06 +0000 (21:35 +0000)]
qemu-options.hx: Fix minor issues in icount documentation
The documentation for the icount documentation has some minor issues:
* in a couple of places it says "sleep=on|off" when in the context of the
sentence it means specifically "sleep=on"
* the synopsis line for the documentation has drifted out of sync
with the synopsis line in the DEF() macro (used for "-help" output)
* the synopsis line in the DEF() macro is missing a "][" between
the sleep= part and the rr= part
* the synopsis line doesn't indicate that rrsnapshot is an optional
part of the rr=mode,rrfile=filename subgrouping
* we don't document that sleep=on can't be used with shift=auto
or align=on
* the rr option description had some minor grammar and formatting
errors and was a bit terse
* in commit
f1f4b57e88ff in 2015 the documentation of the sleep=
suboption got added between the two paragraphs defining general
behaviour of the icount option. This meant that the second
paragraph talking about the behaviour of "this option" reads as
if it's talking about sleep=on, when it's really describing -icount
as a whole. The paragraph is better moved back up to above the
sleep= section.
* the summary text displayed in "-help" output didn't mention
the record-and-replay part
Fix these errors.
Fixes: https://bugs.launchpad.net/qemu/+bug/
1774412
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <
20201121213506.15599-1-peter.maydell@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Dov Murik [Tue, 3 Nov 2020 10:07:45 +0000 (10:07 +0000)]
target/i386: tracing: format length values as hex
Three trace events had a literal "0x" prefix but the 'len' values were
formatted in decimal base. Keep the prefix and format the numbers as
hex, as is usually the case for length of memory regions.
Signed-off-by: Dov Murik <dovmurik@linux.vnet.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <
20201103100745.160409-1-dovmurik@linux.vnet.ibm.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Peter Maydell [Sat, 12 Dec 2020 18:33:46 +0000 (18:33 +0000)]
Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-6.0-pull-request' into staging
m68k pull request
20201212
Fix for Coverity CID
1421883
Fix some comment spelling errors
Add m68k vmstate
# gpg: Signature made Sat 12 Dec 2020 17:54:28 GMT
# gpg: using RSA key
CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C
# gpg: issuer "laurent@vivier.eu"
# gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full]
# gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full]
# gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full]
# Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C
* remotes/vivier/tags/m68k-for-6.0-pull-request:
m68k: fix some comment spelling errors
target/m68k: Add vmstate definition for M68kCPU
target/m68k: remove useless qregs array
hw/m68k/q800.c: Make the GLUE chip an actual QOM device
hw/m68k/q800: Don't connect two qemu_irqs directly to the same input
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
zhaolichang [Fri, 9 Oct 2020 06:44:43 +0000 (14:44 +0800)]
m68k: fix some comment spelling errors
I found that there are many spelling errors in the comments of qemu/target/m68k.
I used spellcheck to check the spelling errors and found some errors in the folder.
Signed-off-by: zhaolichang <zhaolichang@huawei.com>
Reviewed-by: David Edmondson <david.edmondson@oracle.com>
Reviewed-by: Philippe Mathieu-Daude<f4bug@amsat.org>
Reviewed-by: Laurent Vivier<laurent@vivier.eu>
Message-Id: <
20201009064449.2336-9-zhaolichang@huawei.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Laurent Vivier [Thu, 22 Oct 2020 20:30:00 +0000 (22:30 +0200)]
target/m68k: Add vmstate definition for M68kCPU
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <
20201022203000.
1922749-3-laurent@vivier.eu>
Laurent Vivier [Thu, 22 Oct 2020 20:29:59 +0000 (22:29 +0200)]
target/m68k: remove useless qregs array
They are unused since the target has been converted to TCG.
Fixes:
e1f3808e03f7 ("Convert m68k target to TCG.")
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <
20201022203000.
1922749-2-laurent@vivier.eu>
Peter Maydell [Fri, 6 Nov 2020 23:51:09 +0000 (23:51 +0000)]
hw/m68k/q800.c: Make the GLUE chip an actual QOM device
The handling of the GLUE (General Logic Unit) device is
currently open-coded. Make this into a proper QOM device.
This minor piece of modernisation gets rid of the free
floating qemu_irq array 'pic', which Coverity points out
is technically leaked when we exit the machine init function.
(The replacement glue device is not leaked because it gets
added to the sysbus, so it's accessible via that.)
Fixes: Coverity CID
1421883
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Laurent vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <
20201106235109.7066-3-peter.maydell@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Peter Maydell [Fri, 6 Nov 2020 23:51:08 +0000 (23:51 +0000)]
hw/m68k/q800: Don't connect two qemu_irqs directly to the same input
The q800 board code connects both of the IRQ outputs of the ESCC
to the same pic[3] qemu_irq. Connecting two qemu_irqs outputs directly
to the same input is not valid as it produces subtly wrong behaviour
(for instance if both the IRQ lines are high, and then one goes
low, the PIC input will see this as a high-to-low transition
even though the second IRQ line should still be holding it high).
This kind of wiring needs an explicitly created OR gate; add one.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <
20201106235109.7066-2-peter.maydell@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Peter Maydell [Sat, 12 Dec 2020 00:20:45 +0000 (00:20 +0000)]
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
Block layer patches:
- Support for FUSE exports
- Fix deadlock in bdrv_co_yield_to_drain()
- Use lock guard macros
- Some preparational patches for 64 bit block layer
- file-posix: Fix request extension to INT64_MAX in raw_do_pwrite_zeroes()
# gpg: Signature made Fri 11 Dec 2020 17:06:19 GMT
# gpg: using RSA key
DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg: issuer "kwolf@redhat.com"
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* remotes/kevin/tags/for-upstream: (34 commits)
block: Fix deadlock in bdrv_co_yield_to_drain()
block: Fix locking in qmp_block_resize()
block: Simplify qmp_block_resize() error paths
block: introduce BDRV_MAX_LENGTH
block/io: bdrv_check_byte_request(): drop bdrv_is_inserted()
block/io: bdrv_refresh_limits(): use ERRP_GUARD
block/file-posix: fix workaround in raw_do_pwrite_zeroes()
can-host: Fix crash when 'canbus' property is not set
iotests/221: Discard image before qemu-img map
file-posix: check the use_lock before setting the file lock
iotests/308: Add test for FUSE exports
iotests: Enable fuse for many tests
iotests: Allow testing FUSE exports
iotests: Give access to the qemu-storage-daemon
storage-daemon: Call bdrv_close_all() on exit
iotests/287: Clean up subshell test image
iotests: Let _make_test_img guess $TEST_IMG_FILE
iotests: Restrict some Python tests to file
iotests/091: Use _cleanup_qemu instad of "wait"
iotests: Derive image names from $TEST_IMG
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 11 Dec 2020 22:22:50 +0000 (22:22 +0000)]
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-
20201211' into staging
First set of 6.0 patches for s390x:
- acceptance test for device detection
- bugfixes
# gpg: Signature made Fri 11 Dec 2020 12:21:45 GMT
# gpg: using RSA key
C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF
# gpg: issuer "cohuck@redhat.com"
# gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [unknown]
# gpg: aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" [full]
# gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>" [full]
# gpg: aka "Cornelia Huck <cohuck@kernel.org>" [unknown]
# gpg: aka "Cornelia Huck <cohuck@redhat.com>" [unknown]
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF
* remotes/cohuck/tags/s390x-
20201211:
s390x/cpu: Use timer_free() in the finalize function to avoid memleaks
tests/acceptance: test s390x zpci fid propagation
tests/acceptance: verify s390x device detection
tests/acceptance: test virtio-ccw revision handling
tests/acceptance: add a test for devices on s390x
hw/watchdog/wdt_diag288: Remove unnecessary includes
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 11 Dec 2020 16:55:52 +0000 (16:55 +0000)]
Merge remote-tracking branch 'remotes/kraxel/tags/ui-
20201211-pull-request' into staging
ui/console ui_info tweaks.
ui/vnc: alpha cursor support.
ui/vnc: locking fixes.
ui/sdl: add extra mouse buttons.
# gpg: Signature made Fri 11 Dec 2020 09:12:39 GMT
# gpg: using RSA key
4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full]
# gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full]
# gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full]
# Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138
* remotes/kraxel/tags/ui-
20201211-pull-request:
sdl2: Add extra mouse buttons
ui/vnc: Add missing lock for send_color_map
vnc: add alpha cursor support
vnc: add pseudo encodings
vnc: drop unused copyrect feature
vnc: use enum for features
console: allow con==NULL in dpy_{get, set}_ui_info and dpy_ui_info_supported
console: drop qemu_console_get_ui_info
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Kevin Wolf [Thu, 3 Dec 2020 17:23:11 +0000 (18:23 +0100)]
block: Fix deadlock in bdrv_co_yield_to_drain()
If bdrv_co_yield_to_drain() is called for draining a block node that
runs in a different AioContext, it keeps that AioContext locked while it
yields and schedules a BH in the AioContext to do the actual drain.
As long as executing the BH is the very next thing that the event loop
of the node's AioContext does, this actually happens to work, but when
it tries to execute something else that wants to take the AioContext
lock, it will deadlock. (In the bug report, this other thing is a
virtio-scsi device running virtio_scsi_data_plane_handle_cmd().)
Instead, always drop the AioContext lock across the yield and reacquire
it only when the coroutine is reentered. The BH needs to unconditionally
take the lock for itself now.
This fixes the 'block_resize' QMP command on a block node that runs in
an iothread.
Cc: qemu-stable@nongnu.org
Fixes:
eb94b81a94bce112e6b206df846c1551aaf6cab6
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=
1903511
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201203172311.68232-4-kwolf@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Kevin Wolf [Thu, 3 Dec 2020 17:23:10 +0000 (18:23 +0100)]
block: Fix locking in qmp_block_resize()
The drain functions assume that we hold the AioContext lock of the
drained block node. Make sure to actually take the lock.
Cc: qemu-stable@nongnu.org
Fixes:
eb94b81a94bce112e6b206df846c1551aaf6cab6
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201203172311.68232-3-kwolf@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Kevin Wolf [Thu, 3 Dec 2020 17:23:09 +0000 (18:23 +0100)]
block: Simplify qmp_block_resize() error paths
The only thing that happens after the 'out:' label is blk_unref(blk).
However, blk = NULL in all of the error cases, so instead of jumping to
'out:', we can just return directly.
Cc: qemu-stable@nongnu.org
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201203172311.68232-2-kwolf@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Vladimir Sementsov-Ogievskiy [Thu, 3 Dec 2020 22:27:13 +0000 (01:27 +0300)]
block: introduce BDRV_MAX_LENGTH
We are going to modify block layer to work with 64bit requests. And
first step is moving to int64_t type for both offset and bytes
arguments in all block request related functions.
It's mostly safe (when widening signed or unsigned int to int64_t), but
switching from uint64_t is questionable.
So, let's first establish the set of requests we want to work with.
First signed int64_t should be enough, as off_t is signed anyway. Then,
obviously offset + bytes should not overflow.
And most interesting: (offset + bytes) being aligned up should not
overflow as well. Aligned to what alignment? First thing that comes in
mind is bs->bl.request_alignment, as we align up request to this
alignment. But there is another thing: look at
bdrv_mark_request_serialising(). It aligns request up to some given
alignment. And this parameter may be bdrv_get_cluster_size(), which is
often a lot greater than bs->bl.request_alignment.
Note also, that bdrv_mark_request_serialising() uses signed int64_t for
calculations. So, actually, we already depend on some restrictions.
Happily, bdrv_get_cluster_size() returns int and
bs->bl.request_alignment has 32bit unsigned type, but defined to be a
power of 2 less than INT_MAX. So, we may establish, that INT_MAX is
absolute maximum for any kind of alignment that may occur with the
request.
Note, that bdrv_get_cluster_size() is not documented to return power
of 2, still bdrv_mark_request_serialising() behaves like it is.
Also, backup uses bdi.cluster_size and is not prepared to it not being
power of 2.
So, let's establish that Qemu supports only power-of-2 clusters and
alignments.
So, alignment can't be greater than 2^30.
Finally to be safe with calculations, to not calculate different
maximums for different nodes (depending on cluster size and
request_alignment), let's simply set QEMU_ALIGN_DOWN(INT64_MAX, 2^30)
as absolute maximum bytes length for Qemu. Actually, it's not much less
than INT64_MAX.
OK, then, let's apply it to block/io.
Let's consider all block/io entry points of offset/bytes:
4 bytes/offset interface functions: bdrv_co_preadv_part(),
bdrv_co_pwritev_part(), bdrv_co_copy_range_internal() and
bdrv_co_pdiscard() and we check them all with bdrv_check_request().
We also have one entry point with only offset: bdrv_co_truncate().
Check the offset.
And one public structure: BdrvTrackedRequest. Happily, it has only
three external users:
file-posix.c: adopted by this patch
write-threshold.c: only read fields
test-write-threshold.c: sets obviously small constant values
Better is to make the structure private and add corresponding
interfaces.. Still it's not obvious what kind of interface is needed
for file-posix.c. Let's keep it public but add corresponding
assertions.
After this patch we'll convert functions in block/io.c to int64_t bytes
and offset parameters. We can assume that offset/bytes pair always
satisfy new restrictions, and make
corresponding assertions where needed. If we reach some offset/bytes
point in block/io.c missing bdrv_check_request() it is considered a
bug. As well, if block/io.c modifies a offset/bytes request, expanding
it more then aligning up to request_alignment, it's a bug too.
For all io requests except for discard we keep for now old restriction
of 32bit request length.
iotest 206 output error message changed, as now test disk size is
larger than new limit. Add one more test case with new maximum disk
size to cover too-big-L1 case.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <
20201203222713.13507-5-vsementsov@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Vladimir Sementsov-Ogievskiy [Thu, 3 Dec 2020 22:27:12 +0000 (01:27 +0300)]
block/io: bdrv_check_byte_request(): drop bdrv_is_inserted()
Move bdrv_is_inserted() calls into callers.
We are going to make bdrv_check_byte_request() a clean thing.
bdrv_is_inserted() is not about checking the request, it's about
checking the bs. So, it should be separate.
With this patch we probably change error path for some failure
scenarios. But depending on the fact that querying too big request on
empty cdrom (or corrupted qcow2 node with no drv) will result in EIO
and not ENOMEDIUM would be very strange. More over, we are going to
move to 64bit requests, so larger requests will be allowed anyway.
More over, keeping in mind that cdrom is the only driver that has
.bdrv_is_inserted() handler it's strange that we should care so much
about it in generic block layer, intuitively we should just do read and
write, and cdrom driver should return correct errors if it is not
inserted. But it's a work for another series.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <
20201203222713.13507-4-vsementsov@virtuozzo.com>
Reviewed-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Vladimir Sementsov-Ogievskiy [Thu, 3 Dec 2020 22:27:11 +0000 (01:27 +0300)]
block/io: bdrv_refresh_limits(): use ERRP_GUARD
This simplifies following commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <
20201203222713.13507-3-vsementsov@virtuozzo.com>
Reviewed-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Vladimir Sementsov-Ogievskiy [Thu, 3 Dec 2020 22:27:10 +0000 (01:27 +0300)]
block/file-posix: fix workaround in raw_do_pwrite_zeroes()
We should not set overlap_bytes:
1. Don't worry: it is calculated by bdrv_mark_request_serialising() and
will be equal to or greater than bytes anyway.
2. If the request was already aligned up to some greater alignment,
than we may break things: we reduce overlap_bytes, and further
bdrv_mark_request_serialising() may not help, as it will not restore
old bigger alignment.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <
20201203222713.13507-2-vsementsov@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Kevin Wolf [Mon, 30 Nov 2020 10:56:15 +0000 (11:56 +0100)]
can-host: Fix crash when 'canbus' property is not set
Providing the 'if' property, but not 'canbus' segfaults like this:
#0 0x0000555555b0f14d in can_bus_insert_client (bus=0x0, client=0x555556aa9af0) at ../net/can/can_core.c:88
#1 0x00005555559c3803 in can_host_connect (ch=0x555556aa9ac0, errp=0x7fffffffd568) at ../net/can/can_host.c:62
#2 0x00005555559c386a in can_host_complete (uc=0x555556aa9ac0, errp=0x7fffffffd568) at ../net/can/can_host.c:72
#3 0x0000555555d52de9 in user_creatable_complete (uc=0x555556aa9ac0, errp=0x7fffffffd5c8) at ../qom/object_interfaces.c:23
Add the missing NULL check.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201130105615.21799-5-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Mon, 7 Dec 2020 15:22:45 +0000 (16:22 +0100)]
iotests/221: Discard image before qemu-img map
See the new comment for why this should be done.
I do not have a reproducer on master, but when using FUSE block exports,
this test breaks depending on the underlying filesystem (for me, it
works on tmpfs, but fails on xfs, because the block allocated by
file-posix has 16 kB there instead of 4 kB).
Suggested-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <
20201207152245.66987-1-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Li Feng [Mon, 7 Dec 2020 11:44:06 +0000 (19:44 +0800)]
file-posix: check the use_lock before setting the file lock
The scenario is that when accessing a volume on an NFS filesystem
without supporting the file lock, Qemu will complain "Failed to lock
byte 100", even when setting the file.locking = off.
We should do file lock related operations only when the file.locking is
enabled, otherwise, the syscall of 'fcntl' will return non-zero.
Signed-off-by: Li Feng <fengli@smartx.com>
Message-Id: <
1607341446-85506-1-git-send-email-fengli@smartx.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:06:00 +0000 (20:06 +0100)]
iotests/308: Add test for FUSE exports
We have good coverage of the normal I/O paths now, but what remains is a
test that tests some more special cases: Exporting an image on itself
(thus turning a formatted image into a raw one), some error cases, and
non-writable and non-growable exports.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201027190600.192171-21-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:59 +0000 (20:05 +0100)]
iotests: Enable fuse for many tests
Many tests (that do not support generic protocols) can run just fine
with FUSE-exported images, so allow them to. Note that this is no
attempt at being definitely complete. There are some tests that might
be modified to run on FUSE, but this patch still skips them. This patch
only tries to pick the rather low-hanging fruits.
Note that 221 and 250 only pass when .lseek is correctly implemented,
which is only possible with a libfuse that is 3.8 or newer.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201027190600.192171-20-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:58 +0000 (20:05 +0100)]
iotests: Allow testing FUSE exports
This pretends FUSE exports are a kind of protocol. As such, they are
always tested under the format node. This is probably the best way to
test them, actually, because this will generate more I/O load and more
varied patterns.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <
20201027190600.192171-19-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:57 +0000 (20:05 +0100)]
iotests: Give access to the qemu-storage-daemon
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <
20201027190600.192171-18-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:56 +0000 (20:05 +0100)]
storage-daemon: Call bdrv_close_all() on exit
Otherwise, exports and block devices are not properly shut down and
closed, unless the users explicitly issues blockdev-del and
block-export-del commands for each of them.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201027190600.192171-17-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:55 +0000 (20:05 +0100)]
iotests/287: Clean up subshell test image
287 creates an image in a subshell (thanks to the pipe) to see whether
that is possible with compression_type=zstd. If _make_test_img were to
modify any global state, this global state would then be lost before we
could cleanup the image.
When using FUSE as the test protocol, this global state is important, so
clean up the image before the state is lost.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201027190600.192171-16-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:54 +0000 (20:05 +0100)]
iotests: Let _make_test_img guess $TEST_IMG_FILE
When most iotests want to create a test image that is named differently
from the default $TEST_IMG, they do something like this:
TEST_IMG="$TEST_IMG.base" _make_test_img $options
This works fine with the "file" protocol, but not so much for anything
else: _make_test_img tries to create an image under $TEST_IMG_FILE
first, and only under $TEST_IMG if the former is not set; and on
everything but "file", $TEST_IMG_FILE is set.
There are two ways we can fix this: First, we could make all tests
adjust not only TEST_IMG, but also TEST_IMG_FILE if that is present
(e.g. with something like _set_test_img_suffix $suffix that would affect
not only TEST_IMG but also TEST_IMG_FILE, if necessary). This is a
pretty clean solution, and this is maybe what we should have done from
the start.
But it would also require changes to most existing bash tests. So the
alternative is this: Let _make_test_img see whether $TEST_IMG_FILE still
points to the original value. If so, it is possible that the caller has
adjusted $TEST_IMG but not $TEST_IMG_FILE. In such a case, we can (for
most protocols) derive the corresponding $TEST_IMG_FILE value from
$TEST_IMG value and thus work around what technically is the caller
misbehaving.
This second solution is less clean, but it is robust against people
keeping their old habit of adjusting TEST_IMG only, and requires much
less changes. So this patch implements it.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201027190600.192171-15-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:53 +0000 (20:05 +0100)]
iotests: Restrict some Python tests to file
Most Python tests are restricted to the file protocol (without
explicitly saying so), but these are the ones that would break
./check -fuse -qcow2.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201027190600.192171-14-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:52 +0000 (20:05 +0100)]
iotests/091: Use _cleanup_qemu instad of "wait"
If the test environment has some other child processes running (like a
storage daemon that provides a FUSE export), then "wait" will never
finish. Use wait=yes _cleanup_qemu instead.
(We need to discard the output so there is no change to the reference
output.)
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201027190600.192171-13-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:51 +0000 (20:05 +0100)]
iotests: Derive image names from $TEST_IMG
Avoid creating images with custom filenames in $TEST_DIR, because
non-file protocols may want to keep $TEST_IMG (and all other test
images) in some other directory.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201027190600.192171-12-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:50 +0000 (20:05 +0100)]
iotests/046: Avoid renaming images
This generally does not work on non-file protocols. It is better to
create the image with the final name from the start, and most tests do
this already. Let 046 follow suit.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201027190600.192171-11-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:49 +0000 (20:05 +0100)]
iotests: Use convert -n in some cases
qemu-img convert (without -n) can often be replaced by a combination of
_make_test_img + qemu-img convert -n. Doing so allows converting to
protocols that do not allow direct file creation, such as FUSE exports.
The only problem is that for formats other than qcow2 and qed (qcow1 at
least), this may lead to high disk usage for some reason, so we cannot
do it everywhere.
But we can do it in 028 and 089, so let us do that so they can run on
FUSE exports. Also, in 028 this allows us to remove a 9-line comment
that used to explain why we cannot safely filter drive-backup's image
creation output.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201027190600.192171-10-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:48 +0000 (20:05 +0100)]
iotests: Do not pipe _make_test_img
Executing _make_test_img as part of a pipe will undo all variable
changes it has done. As such, this could not work with FUSE (because
we want to remember all of our exports and their qemu instances).
Replace the pipe by a temporary file in 071 and 174 (the two tests that
can run on FUSE).
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201027190600.192171-9-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:47 +0000 (20:05 +0100)]
iotests: Do not needlessly filter _make_test_img
In most cases, _make_test_img does not need a _filter_imgfmt on top. It
does that by itself.
(The exception is when IMGFMT has been overwritten but TEST_IMG has not.
In such cases, we do need a _filter_imgfmt on top to filter the test's
original IMGFMT from TEST_IMG.)
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <
20201027190600.192171-8-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:46 +0000 (20:05 +0100)]
fuse: Implement hole detection through lseek
This is a relatively new feature in libfuse (available since 3.8.0,
which was released in November 2019), so we have to add a dedicated
check whether it is available before making use of it.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <
20201027190600.192171-7-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:45 +0000 (20:05 +0100)]
fuse: (Partially) implement fallocate()
This allows allocating areas after the (old) EOF as part of a growing
resize, writing zeroes, and discarding.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <
20201027190600.192171-6-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:44 +0000 (20:05 +0100)]
fuse: Allow growable exports
These will behave more like normal files in that writes beyond the EOF
will automatically grow the export size.
As an optimization, keep the RESIZE permission for growable exports so
we do not have to take it for every post-EOF write. (This permission is
not released when the export is destroyed, because at that point the
BlockBackend is destroyed altogether anyway.)
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <
20201027190600.192171-5-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:43 +0000 (20:05 +0100)]
fuse: Implement standard FUSE operations
This makes the export actually useful instead of only producing errors
whenever it is accessed.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <
20201027190600.192171-4-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:42 +0000 (20:05 +0100)]
fuse: Allow exporting BDSs via FUSE
block-export-add type=fuse allows mounting block graph nodes via FUSE on
some existing regular file. That file should then appears like a raw
disk image, and accesses to it result in accesses to the exported BDS.
Right now, we only implement the necessary block export functions to set
it up and shut it down. We do not implement any access functions, so
accessing the mount point only results in errors. This will be
addressed by a followup patch.
We keep a hash table of exported mount points, because we want to be
able to detect when users try to use a mount point twice. This is
because we invoke stat() to check whether the given mount point is a
regular file, but if that file is served by ourselves (because it is
already used as a mount point), then this stat() would have to be served
by ourselves, too, which is impossible to do while we (as the caller)
are waiting for it to settle. Therefore, keep track of mount point
paths to at least catch the most obvious instances of that problem.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <
20201027190600.192171-3-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Max Reitz [Tue, 27 Oct 2020 19:05:41 +0000 (20:05 +0100)]
meson: Detect libfuse
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <
20201027190600.192171-2-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Gan Qixin [Thu, 3 Dec 2020 07:50:55 +0000 (15:50 +0800)]
block/iscsi: Use lock guard macros
Replace manual lock()/unlock() calls with lock guard macros
(QEMU_LOCK_GUARD/WITH_QEMU_LOCK_GUARD) in block/iscsi.
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Message-Id: <
20201203075055.127773-5-ganqixin@huawei.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Gan Qixin [Thu, 3 Dec 2020 07:50:54 +0000 (15:50 +0800)]
block/throttle-groups: Use lock guard macros
Replace manual lock()/unlock() calls with lock guard macros
(QEMU_LOCK_GUARD/WITH_QEMU_LOCK_GUARD) in block/throttle-groups.
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Message-Id: <
20201203075055.127773-4-ganqixin@huawei.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Gan Qixin [Thu, 3 Dec 2020 07:50:53 +0000 (15:50 +0800)]
block/curl: Use lock guard macros
Replace manual lock()/unlock() calls with lock guard macros
(QEMU_LOCK_GUARD/WITH_QEMU_LOCK_GUARD) in block/curl.
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201203075055.127773-3-ganqixin@huawei.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Gan Qixin [Thu, 3 Dec 2020 07:50:52 +0000 (15:50 +0800)]
block/accounting: Use lock guard macros
Replace manual lock()/unlock() calls with lock guard macros
(QEMU_LOCK_GUARD/WITH_QEMU_LOCK_GUARD) in block/accounting.
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201203075055.127773-2-ganqixin@huawei.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Peter Maydell [Fri, 11 Dec 2020 15:01:05 +0000 (15:01 +0000)]
Merge remote-tracking branch 'remotes/rth-gitlab/tags/pull-tcg-
20201210' into staging
Split CpusAccel for tcg variants
# gpg: Signature made Fri 11 Dec 2020 01:07:33 GMT
# gpg: using RSA key
7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg: issuer "richard.henderson@linaro.org"
# gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full]
# Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F
* remotes/rth-gitlab/tags/pull-tcg-
20201210:
accel/tcg: rename tcg-cpus functions to match module name
accel/tcg: split tcg_start_vcpu_thread
accel/tcg: split CpusAccel into three TCG variants
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 11 Dec 2020 13:50:35 +0000 (13:50 +0000)]
Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into staging
* Fix for NULL segments (Bin Meng)
* Support for 32768 CPUs on x86 without IOMMU (David)
* PDEP/PEXT fix and testcase (myself)
* Remove bios_name and ram_size globals (myself)
* qemu_init rationalization (myself)
* Update kernel-doc (myself + upstream patches)
* Propagate MemTxResult across DMA and PCI functions (Philippe)
* Remove master/slave when applicable (Philippe)
* WHPX support for in-kernel irqchip (Sunil)
# gpg: Signature made Thu 10 Dec 2020 17:21:50 GMT
# gpg: using RSA key
F13338574B662389866C7682BFFBD25F78C7AE83
# gpg: issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full]
# gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full]
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1
# Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83
* remotes/bonzini-gitlab/tags/for-upstream: (113 commits)
scripts: kernel-doc: remove unnecessary change wrt Linux
Revert "docs: temporarily disable the kernel-doc extension"
scripts: kernel-doc: use :c:union when needed
scripts: kernel-doc: split typedef complex regex
scripts: kernel-doc: fix typedef parsing
Revert "kernel-doc: Handle function typedefs that return pointers"
Revert "kernel-doc: Handle function typedefs without asterisks"
scripts: kernel-doc: try to use c:function if possible
scripts: kernel-doc: fix line number handling
scripts: kernel-doc: allow passing desired Sphinx C domain dialect
scripts: kernel-doc: don't mangle with parameter list
scripts: kernel-doc: fix typedef identification
scripts: kernel-doc: reimplement -nofunction argument
scripts: kernel-doc: fix troubles with line counts
scripts: kernel-doc: use a less pedantic markup for funcs on Sphinx 3.x
scripts: kernel-doc: make it more compatible with Sphinx 3.x
Revert "kernel-doc: Use c:struct for Sphinx 3.0 and later"
Revert "scripts/kerneldoc: For Sphinx 3 use c:macro for macros with arguments"
scripts: kernel-doc: add support for typedef enum
kernel-doc: add support for ____cacheline_aligned attribute
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 11 Dec 2020 12:16:33 +0000 (12:16 +0000)]
Merge remote-tracking branch 'remotes/ehabkost/tags/machine-next-pull-request' into staging
Machine queue, 2020-12-10
Some patches that were queued after 5.2 soft freeze.
# gpg: Signature made Thu 10 Dec 2020 22:41:29 GMT
# gpg: using RSA key
5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6
# gpg: issuer "ehabkost@redhat.com"
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full]
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/machine-next-pull-request:
i386/cpu: Make the Intel PT LIP feature configurable
sev: add sev-inject-launch-secret
qom: code hardening - have bound checking while looping with integer value
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Gan Qixin [Fri, 4 Dec 2020 08:12:09 +0000 (16:12 +0800)]
s390x/cpu: Use timer_free() in the finalize function to avoid memleaks
When running device-introspect-test, a memory leak occurred in the s390_cpu_initfn
function, this patch use timer_free() in the finalize function to fix it.
ASAN shows memory leak stack:
Direct leak of 3552 byte(s) in 74 object(s) allocated from:
#0 0xfffeb3d4e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xfffeb36e6800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaad51a8f9c4 in timer_new_full qemu/include/qemu/timer.h:523
#3 0xaaad51a8f9c4 in timer_new qemu/include/qemu/timer.h:544
#4 0xaaad51a8f9c4 in timer_new_ns qemu/include/qemu/timer.h:562
#5 0xaaad51a8f9c4 in s390_cpu_initfn qemu/target/s390x/cpu.c:304
#6 0xaaad51e00f58 in object_init_with_type qemu/qom/object.c:371
#7 0xaaad51e0406c in object_initialize_with_type qemu/qom/object.c:515
#8 0xaaad51e042e0 in object_new_with_type qemu/qom/object.c:729
#9 0xaaad51e3ff40 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153
#10 0xaaad51910518 in qdev_device_help qemu/softmmu/qdev-monitor.c:283
#11 0xaaad51911918 in qmp_device_add qemu/softmmu/qdev-monitor.c:801
#12 0xaaad51911e48 in hmp_device_add qemu/softmmu/qdev-monitor.c:916
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <
20201204081209.360524-4-ganqixin@huawei.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Cornelia Huck [Mon, 30 Nov 2020 18:02:16 +0000 (19:02 +0100)]
tests/acceptance: test s390x zpci fid propagation
Verify that a fid specified on the command line shows up correctly
as the function_id in the guest.
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
[re-formatted overlong lines]
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Message-Id: <
20201130180216.15366-4-cohuck@redhat.com>
Cornelia Huck [Mon, 30 Nov 2020 18:02:15 +0000 (19:02 +0100)]
tests/acceptance: verify s390x device detection
The kernel/initrd combination does not provide the virtio-net
driver; therefore, simply check whether the presented device type
is indeed virtio-net for the two virtio-net-{ccw,pci} devices.
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
[re-formatted overlong lines]
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Message-Id: <
20201130180216.15366-3-cohuck@redhat.com>
Cornelia Huck [Mon, 30 Nov 2020 18:02:14 +0000 (19:02 +0100)]
tests/acceptance: test virtio-ccw revision handling
The max_revision prop of virtio-ccw devices can be used to force
an older revision for compatibility handling. The easiest way to
check this is to force a device to revision 0, which turns off
virtio-1.
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
[re-formatted overlong lines]
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Message-Id: <
20201130180216.15366-2-cohuck@redhat.com>
Cornelia Huck [Thu, 26 Nov 2020 13:01:58 +0000 (14:01 +0100)]
tests/acceptance: add a test for devices on s390x
This adds a very basic test for checking that we present devices
in a way that Linux can consume: boot with both virtio-net-ccw and
virtio-net-pci attached and then verify that Linux is able to see
and detect these devices.
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Message-Id: <
20201126130158.
1471985-1-cohuck@redhat.com>
Thomas Huth [Wed, 18 Nov 2020 09:03:44 +0000 (10:03 +0100)]
hw/watchdog/wdt_diag288: Remove unnecessary includes
Neither sysbus.h nor module.h are required to compile this file.
diag288 is not a sysbus device, and module.h (for type_init) is
included eventually through qom/object.h.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <
20201118090344.243117-1-thuth@redhat.com>
[CH: tweaked description]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Darrell Walisser [Thu, 10 Dec 2020 14:33:06 +0000 (14:33 +0000)]
sdl2: Add extra mouse buttons
Allows guest to receive mouse buttons 4 and 5, aka "SIDE" button
and "EXTRA" button
Signed-off-by: Darrell Walisser <darrell.walisser@gmail.com>
Message-id: GNUALCfDBqhCUvLwBNJaKqxcPewMtlqCnixk8xTrgI@ubuntu
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Peng Liang [Mon, 16 Nov 2020 14:13:38 +0000 (22:13 +0800)]
ui/vnc: Add missing lock for send_color_map
vnc_write() should be locked after the RFB protocol is initialized.
Fixes:
0c426e4534b4 ("vnc: Add support for color map")
Cc: qemu-stable@nongnu.org
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Message-id:
20201116141338.148911-1-liangpeng10@huawei.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Gerd Hoffmann [Tue, 8 Dec 2020 11:57:34 +0000 (12:57 +0100)]
vnc: add alpha cursor support
There is a new vnc extension for cursors with an alpha channel. Use
it if supported by the vnc client, prefer it over the "rich cursor"
extension which supports only a bitmask for transparency.
This is a visible improvement especially on modern desktops which
actually use the alpha channel when defining cursors.
https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#cursor-with-alpha-pseudo-encoding
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id:
20201208115737.18581-7-kraxel@redhat.com
Gerd Hoffmann [Tue, 8 Dec 2020 11:57:33 +0000 (12:57 +0100)]
vnc: add pseudo encodings
Add #defines for two new pseudo encodings:
* cursor with alpha channel.
* extended desktop resize.
https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#pseudo-encodings
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id:
20201208115737.18581-6-kraxel@redhat.com
Gerd Hoffmann [Tue, 8 Dec 2020 11:57:32 +0000 (12:57 +0100)]
vnc: drop unused copyrect feature
vnc stopped using the copyrect pseudo encoding in 2017, in commit
50628d3479e4 ("cirrus/vnc: zap bitblit support from console code.")
So we can drop the now unused copyrect feature bit.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id:
20201208115737.18581-5-kraxel@redhat.com
Gerd Hoffmann [Tue, 8 Dec 2020 11:57:31 +0000 (12:57 +0100)]
vnc: use enum for features
Use an enum for the vnc feature bits. That way they are enumerated
automatically and we don't have to do that manually when adding or
removing features.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id:
20201208115737.18581-4-kraxel@redhat.com
Gerd Hoffmann [Tue, 8 Dec 2020 11:57:30 +0000 (12:57 +0100)]
console: allow con==NULL in dpy_{get, set}_ui_info and dpy_ui_info_supported
Use active_console in that case like we do in many other places.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id:
20201208115737.18581-3-kraxel@redhat.com
Gerd Hoffmann [Tue, 8 Dec 2020 11:57:29 +0000 (12:57 +0100)]
console: drop qemu_console_get_ui_info
Unused and duplicate (there is dpy_get_ui_info).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id:
20201208115737.18581-2-kraxel@redhat.com
Claudio Fontana [Thu, 15 Oct 2020 14:32:17 +0000 (16:32 +0200)]
accel/tcg: rename tcg-cpus functions to match module name
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <
20201015143217.29337-4-cfontana@suse.de>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Claudio Fontana [Thu, 15 Oct 2020 14:32:16 +0000 (16:32 +0200)]
accel/tcg: split tcg_start_vcpu_thread
after the initial split into 3 tcg variants, we proceed to also
split tcg_start_vcpu_thread.
We actually split it in 2 this time, since the icount variant
just uses the round robin function.
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Message-Id: <
20201015143217.29337-3-cfontana@suse.de>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Claudio Fontana [Thu, 15 Oct 2020 14:32:15 +0000 (16:32 +0200)]
accel/tcg: split CpusAccel into three TCG variants
split up the CpusAccel tcg_cpus into three TCG variants:
tcg_cpus_rr (single threaded, round robin cpus)
tcg_cpus_icount (same as rr, but with instruction counting enabled)
tcg_cpus_mttcg (multi-threaded cpus)
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <
20201015143217.29337-2-cfontana@suse.de>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Luwei Kang [Wed, 2 Dec 2020 10:10:42 +0000 (18:10 +0800)]
i386/cpu: Make the Intel PT LIP feature configurable
The current implementation will disable the guest Intel PT feature
if the Intel PT LIP feature is supported on the host, but the LIP
feature is comming soon(e.g. SnowRidge and later).
This patch will make the guest LIP feature configurable and Intel
PT feature can be enabled in guest when the guest LIP status same
with the host.
Signed-off-by: Luwei Kang <luwei.kang@intel.com>
Message-Id: <
20201202101042.11967-1-luwei.kang@intel.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Tobin Feldman-Fitzthum [Tue, 27 Oct 2020 17:03:03 +0000 (13:03 -0400)]
sev: add sev-inject-launch-secret
AMD SEV allows a guest owner to inject a secret blob
into the memory of a virtual machine. The secret is
encrypted with the SEV Transport Encryption Key and
integrity is guaranteed with the Transport Integrity
Key. Although QEMU facilitates the injection of the
launch secret, it cannot access the secret.
Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.ibm.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Message-Id: <
20201027170303.47550-1-tobin@linux.ibm.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Ani Sinha [Mon, 21 Sep 2020 09:33:25 +0000 (15:03 +0530)]
qom: code hardening - have bound checking while looping with integer value
Object property insertion code iterates over an integer to get an unused
index that can be used as an unique name for an object property. This loop
increments the integer value indefinitely. Although very unlikely, this can
still cause an integer overflow.
In this change, we fix the above code by checking against INT16_MAX and making
sure that the interger index does not overflow beyond that value. If no
available index is found, the code would cause an assertion failure. This
assertion failure is necessary because the callers of the function do not check
the return value for NULL.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <
20200921093325.25617-1-ani@anisinha.ca>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Paolo Bonzini [Mon, 30 Nov 2020 12:21:12 +0000 (07:21 -0500)]
scripts: kernel-doc: remove unnecessary change wrt Linux
A comment in kernel-doc mentions QEMU's qatomic_set macro, but since
this code originated in Linux we should just revert it and stay as close
to the kernel's copy of the script as possible.
The change was introduced (more or less unintentionally) in QEMU commit
commit
d73415a31547, which did a global search-and-replace of QEMU's
atomic access macros.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Mon, 30 Nov 2020 12:17:45 +0000 (07:17 -0500)]
Revert "docs: temporarily disable the kernel-doc extension"
This reverts commit
fd68a72875cf318f4310726f842139119c5f45d5. We're
done with the update of kernel-doc and we can restore kernel-doc's
functionality.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:53:12 +0000 (17:53 +0100)]
scripts: kernel-doc: use :c:union when needed
Sphinx C domain code after 3.2.1 will start complaning if :c:struct
would be used for an union type:
.../Documentation/gpu/drm-kms-helpers:352: ../drivers/video/hdmi.c:851: WARNING: C 'identifier' cross-reference uses wrong tag: reference name is 'union hdmi_infoframe' but found name is 'struct hdmi_infoframe'. Full reference name is 'union hdmi_infoframe'. Full found name is 'struct hdmi_infoframe'.
So, let's address this issue too in advance, in order to
avoid future issues.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/6e4ec3eec914df62389a299797a3880ae4490f35.1603791716.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-30-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:53:11 +0000 (17:53 +0100)]
scripts: kernel-doc: split typedef complex regex
The typedef regex for function prototypes are very complex.
Split them into 3 separate regex and then join them using
qr.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/3a4af999a0d62d4ab9dfae1cdefdfcad93383356.1603792384.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-29-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:53:10 +0000 (17:53 +0100)]
scripts: kernel-doc: fix typedef parsing
The include/linux/genalloc.h file defined this typedef:
typedef unsigned long (*genpool_algo_t)(unsigned long *map,unsigned long size,unsigned long start,unsigned int nr,void *data, struct gen_pool *pool, unsigned long start_addr);
Because it has a type composite of two words (unsigned long),
the parser gets the typedef name wrong:
.. c:macro:: long
**Typedef**: Allocation callback function type definition
Fix the regex in order to accept composite types when
defining a typedef for a function pointer.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/328e8018041cc44f7a1684e57f8d111230761c4f.1603792384.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-28-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 17 Nov 2020 16:53:09 +0000 (17:53 +0100)]
Revert "kernel-doc: Handle function typedefs that return pointers"
This reverts commit
19ab6044be0c55d529e875e3ee16fdd5c3b54d33.
We will replace the commit with the fix from Linux.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-27-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 17 Nov 2020 16:53:08 +0000 (17:53 +0100)]
Revert "kernel-doc: Handle function typedefs without asterisks"
This reverts commit
3cd3c5193cde5242e243c25759f85802e267994f.
We will replace the commit with the fix from Linux.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-26-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:53:07 +0000 (17:53 +0100)]
scripts: kernel-doc: try to use c:function if possible
There are a few namespace clashes by using c:macro everywhere:
basically, when using it, we can't have something like:
.. c:struct:: pwm_capture
.. c:macro:: pwm_capture
So, we need to use, instead:
.. c:function:: int pwm_capture (struct pwm_device * pwm, struct pwm_capture * result, unsigned long timeout)
for the function declaration.
The kernel-doc change was proposed by Jakob Lykke Andersen here:
https://github.com/jakobandersen/linux_docs/commit/
6fd2076ec001cca7466857493cd678df4dfe4a65
Although I did a different implementation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-25-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:53:06 +0000 (17:53 +0100)]
scripts: kernel-doc: fix line number handling
Address several issues related to pointing to the wrong line
number:
1) ensure that line numbers will always be initialized
When section is the default (Description), the line number
is not initializing, producing this:
$ ./scripts/kernel-doc --enable-lineno ./drivers/media/v4l2-core/v4l2-mem2mem.c|less
**Description**
#define LINENO 0
In case of streamoff or release called on any context,
1] If the context is currently running, then abort job will be called
2] If the context is queued, then the context will be removed from
the job_queue
Which is not right. Ensure that the line number will always
be there. After applied, the result now points to the right location:
**Description**
#define LINENO 410
In case of streamoff or release called on any context,
1] If the context is currently running, then abort job will be called
2] If the context is queued, then the context will be removed from
the job_queue
2) The line numbers for function prototypes are always + 1,
because it is taken at the line after handling the prototype.
Change the logic to point to the next line after the /** */
block;
3) The "DOC:" line number should point to the same line as this
markup is found, and not to the next one.
Probably part of the issues were due to a but that was causing
the line number offset to be incremented by one, if --export
were used.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-24-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:53:05 +0000 (17:53 +0100)]
scripts: kernel-doc: allow passing desired Sphinx C domain dialect
When kernel-doc is called via kerneldoc.py, there's no need to
auto-detect the Sphinx version, as the Sphinx module already
knows it. So, add an optional parameter to allow changing the
Sphinx dialect.
As kernel-doc can also be manually called, keep the auto-detection
logic if the parameter was not specified. On such case, emit
a warning if sphinx-build can't be found at PATH.
I ended using a suggestion from Joe for using a more readable
regex, instead of using a complex one with a hidden group like:
m/^(\d+)\.(\d+)(?:\.?(\d+)?)/
in order to get the optional <patch> argument.
Thanks-to: Joe Perches <joe@perches.com>
Suggested-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-23-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:53:04 +0000 (17:53 +0100)]
scripts: kernel-doc: don't mangle with parameter list
While kernel-doc needs to parse parameters in order to
identify its name, it shouldn't be touching the type,
as parsing it is very difficult, and errors happen.
One current error is when parsing this parameter:
const u32 (*tab)[256]
Found at ./lib/crc32.c, on this function:
u32 __pure crc32_be_generic (u32 crc, unsigned char const *p, size_t len, const u32 (*tab)[256], u32 polynomial);
The current logic mangles it, producing this output:
const u32 ( *tab
That's something that it is not recognizeable.
So, instead, let's push the argument as-is, and use it
when printing the function prototype and when describing
each argument.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-22-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:53:03 +0000 (17:53 +0100)]
scripts: kernel-doc: fix typedef identification
Some typedef expressions are output as normal functions.
As we need to be clearer about the type with Sphinx 3.x,
detect such cases.
While here, fix a wrongly-indented block.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-21-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:53:02 +0000 (17:53 +0100)]
scripts: kernel-doc: reimplement -nofunction argument
Right now, the build system doesn't use -nofunction, as
it is pretty much useless, because it doesn't consider
the other output modes (extern, internal), working only
with all.
Also, it is limited to exclude functions.
Re-implement it in order to allow excluding any symbols from
the document output, no matter what mode is used.
The parameter was also renamed to "-nosymbol", as it express
better its meaning.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-20-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:53:01 +0000 (17:53 +0100)]
scripts: kernel-doc: fix troubles with line counts
There's currently a bug with the way kernel-doc script
counts line numbers that can be seen with:
$ ./scripts/kernel-doc -rst -enable-lineno include/linux/math64.h >all && ./scripts/kernel-doc -rst -internal -enable-lineno include/linux/math64.h >int && diff -U0 int all
--- int 2020-09-28 12:58:08.
927486808 +0200
+++ all 2020-09-28 12:58:08.
905486845 +0200
@@ -1 +1 @@
-#define LINENO 27
+#define LINENO 26
@@ -3 +3 @@
-#define LINENO 16
+#define LINENO 15
@@ -9 +9 @@
-#define LINENO 17
+#define LINENO 16
...
This is happening with perl version 5.30.3, but I'm not
so sure if this is a perl bug, or if this is due to something
else.
In any case, fixing it is easy. Basically, when "-internal"
parameter is used, the process_export_file() function opens the
handle "IN". This makes the line number to be incremented, as the
handler for the main open is also "IN".
Fix the problem by using a different handler for the
main open().
While here, add a missing close for it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-19-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:53:00 +0000 (17:53 +0100)]
scripts: kernel-doc: use a less pedantic markup for funcs on Sphinx 3.x
Unfortunately, Sphinx 3.x parser for c functions is too pedantic:
https://github.com/sphinx-doc/sphinx/issues/8241
While it could be relaxed with some configurations, there are
several corner cases that it would make it hard to maintain,
and will require teaching conf.py about several macros.
So, let's instead use the :c:macro notation. This will
produce an output that it is not as nice as currently, but it
should still be acceptable, and will provide cross-references,
removing thousands of warnings when building with newer
versions of Sphinx.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-18-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:52:59 +0000 (17:52 +0100)]
scripts: kernel-doc: make it more compatible with Sphinx 3.x
With Sphinx 3.x, the ".. c:type:" tag was changed to accept either:
.. c:type:: typedef-like declaration
.. c:type:: name
Using it for other types (including functions) don't work anymore.
So, there are newer tags for macro, enum, struct, union, and others,
which doesn't exist on older versions.
Add a check for the Sphinx version and change the produced tags
accordingly.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-17-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 17 Nov 2020 16:52:58 +0000 (17:52 +0100)]
Revert "kernel-doc: Use c:struct for Sphinx 3.0 and later"
This reverts commit
152d1967f650f67b7ece3a5dda77d48069d72647.
We will replace the commit with the fix from Linux.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-16-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 17 Nov 2020 16:52:57 +0000 (17:52 +0100)]
Revert "scripts/kerneldoc: For Sphinx 3 use c:macro for macros with arguments"
This reverts commit
92bb29f9b2c3d4a98eef5f0db935d4be291eec72.
We will replace the commit with the fix from Linux.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-15-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:52:56 +0000 (17:52 +0100)]
scripts: kernel-doc: add support for typedef enum
The PHY kernel-doc markup has gained support for documenting
a typedef enum.
However, right now the parser was not prepared for it.
So, add support for parsing it.
Fixes:
4069a572d423 ("net: phy: Document core PHY structures")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-14-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Jonathan Cameron [Tue, 17 Nov 2020 16:52:55 +0000 (17:52 +0100)]
kernel-doc: add support for ____cacheline_aligned attribute
Subroutine dump_struct uses type attributes to check if the struct
syntax is valid. Then, it removes all attributes before using it for
output. `____cacheline_aligned` is an attribute that is
not included in both steps. Add it, since it is used by kernel structs.
Based on previous patch to add ____cacheline_aligned_in_smp.
Motivated by patches to reorder this attribute to before the
variable name. Whilst we could do that in all cases, that would
be a massive change and it is more common in the kernel to place
this particular attribute after the variable name. A quick grep
suggests approximately 400 instances of which 341 have this
attribute just before a semicolon and hence after the variable name.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200910185415.653139-1-jic23@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-13-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:52:54 +0000 (17:52 +0100)]
kernel-doc: include line numbers for function prototypes
This should solve bad error reports like this one:
./include/linux/iio/iio.h:0: WARNING: Unknown target name: "devm".
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/56eed0ba50cd726236acd12b11b55ce54854c5ea.1599660067.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-12-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Pierre-Louis Bossart [Tue, 17 Nov 2020 16:52:53 +0000 (17:52 +0100)]
scripts/kernel-doc: optionally treat warnings as errors
The kbuild bot recently added the W=1 option, which triggered
documentation cleanups to squelch hundreds of kernel-doc warnings.
To make sure new kernel contributions don't add regressions to
kernel-doc descriptors, this patch suggests an option to treat
warnings as errors in CI/automated tests.
A -Werror command-line option is added to the kernel-doc script. When
this option is set, the script will return the number of warnings
found. The caller can then treat this positive return value as an
error and stop the build.
Using this command line option is however not straightforward when the
kernel-doc script is called from other scripts. To align with typical
kernel compilation or documentation generation, the Werror option is
also set by checking the KCFLAGS environment variable, or if
KDOC_WERROR is defined, as in the following examples:
KCFLAGS="-Wall -Werror" make W=1 sound/
KCFLAGS="-Wall -Werror" make W=1 drivers/soundwire/
KDOC_WERROR=1 make htmldocs
Note that in the last example the documentation build does not stop,
only an additional log is provided.
Credits to Randy Dunlap for suggesting the use of environment variables.
Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200728162040.92467-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-11-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:52:52 +0000 (17:52 +0100)]
scripts/kernel-doc: handle function pointer prototypes
There are some function pointer prototypes inside the net
includes, like this one:
int (*pcs_config)(struct phylink_config *config, unsigned int mode,
phy_interface_t interface, const unsigned long *advertising);
There's nothing wrong using it with kernel-doc, but we need to
add a rule for it to parse such kind of prototype.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/fec520dd731a273013ae06b7653a19c7d15b9562.1592895969.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-10-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:52:51 +0000 (17:52 +0100)]
scripts/kernel-doc: parse __ETHTOOL_DECLARE_LINK_MODE_MASK
The __ETHTOOL_DECLARE_LINK_MODE_MASK macro is a variant of
DECLARE_BITMAP(), used by phylink.h. As we have already a
parser for DECLARE_BITMAP(), let's add one for this macro,
in order to avoid such warnings:
./include/linux/phylink.h:54: warning: Function parameter or member '__ETHTOOL_DECLARE_LINK_MODE_MASK(advertising' not described in 'phylink_link_state'
./include/linux/phylink.h:54: warning: Function parameter or member '__ETHTOOL_DECLARE_LINK_MODE_MASK(lp_advertising' not described in 'phylink_link_state'
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/d1d1dea67a28117c0b0c33271b139c4455fef287.1592895969.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-9-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Alexander A. Klimov [Tue, 17 Nov 2020 16:52:50 +0000 (17:52 +0100)]
Replace HTTP links with HTTPS ones: documentation
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Link: https://lore.kernel.org/r/20200526060544.25127-1-grandmaster@al2klimov.de
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-8-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:52:49 +0000 (17:52 +0100)]
scripts: kernel-doc: accept blank lines on parameter description
Sphinx is very pedantic with respect to blank lines. Sometimes,
in order to make it to properly handle something, we need to
add a blank line. However, currently, any blank line inside a
kernel-doc comment like:
/*
* @foo: bar
*
* foobar
*
* some description
will be considered as if "foobar" was part of the description.
This patch changes kernel-doc behavior. After it, foobar will
be considered as part of the parameter text. The description
will only be considered as such if it starts with:
zero spaces after asterisk:
*foo
one space after asterisk:
* foo
or have a explicit Description section:
* Description:
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/c07d2862792d75a2691d69c9eceb7b89a0164cc0.1586881715.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-7-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:52:48 +0000 (17:52 +0100)]
scripts: kernel-doc: accept negation like !@var
On a few places, it sometimes need to indicate a negation of a
parameter, like:
!@fshared
This pattern happens, for example, at:
kernel/futex.c
and it is perfectly valid. However, kernel-doc currently
transforms it into:
!**fshared**
This won't do what it would be expected.
Fortunately, fixing the script is a simple matter of storing
the "!" before "@" and adding it after the bold markup, like:
**!fshared**
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/0314b47f8c3e1f9db00d5375a73dc3cddd8a21f2.1586881715.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-6-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mauro Carvalho Chehab [Tue, 17 Nov 2020 16:52:47 +0000 (17:52 +0100)]
scripts: kernel-doc: proper handle @foo->bar()
The pattern @foo->bar() is valid, as it can be used by a
function pointer inside a struct passed as a parameter.
Right now, it causes a warning:
./drivers/firewire/core-transaction.c:606: WARNING: Inline strong start-string without end-string.
In this specific case, the kernel-doc markup is:
/**
* fw_core_remove_address_handler() - unregister an address handler
* @handler: callback
*
* To be called in process context.
*
* When fw_core_remove_address_handler() returns, @handler->callback() is
* guaranteed to not run on any CPU anymore.
*/
With seems valid on my eyes. So, instead of trying to hack
the kernel-doc markup, let's teach it about how to handle
such things. This should likely remove lots of other similar
warnings as well.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/48b46426d7bf6ff7529f20e5718fbf4e9758e62c.1586881715.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-5-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Jonathan Neuschäfer [Tue, 17 Nov 2020 16:52:46 +0000 (17:52 +0100)]
scripts/kernel-doc: Add support for named variable macro arguments
Currently, when kernel-doc encounters a macro with a named variable
argument[1], such as this:
#define hlist_for_each_entry_rcu(pos, head, member, cond...)
... it expects the variable argument to be documented as `cond...`,
rather than `cond`. This is semantically wrong, because the name (as
used in the macro body) is actually `cond`.
With this patch, kernel-doc will accept the name without dots (`cond`
in the example above) in doc comments, and warn if the name with dots
(`cond...`) is used and verbose mode[2] is enabled.
The support for the `cond...` syntax can be removed later, when the
documentation of all such macros has been switched to the new syntax.
Testing this patch on top of v5.4-rc6, `make htmldocs` shows a few
changes in log output and HTML output:
1) The following warnings[3] are eliminated:
./include/linux/rculist.h:374: warning:
Excess function parameter 'cond' description in 'list_for_each_entry_rcu'
./include/linux/rculist.h:651: warning:
Excess function parameter 'cond' description in 'hlist_for_each_entry_rcu'
2) For list_for_each_entry_rcu and hlist_for_each_entry_rcu, the
correct description is shown
3) Named variable arguments are shown without dots
[1]: https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
[2]: scripts/kernel-doc -v
[3]: See also https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=dev&id=
5bc4bc0d6153617eabde275285b7b5a8137fdf3c
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Tested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-4-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
André Almeida [Tue, 17 Nov 2020 16:52:45 +0000 (17:52 +0100)]
kernel-doc: add support for ____cacheline_aligned_in_smp attribute
Subroutine dump_struct uses type attributes to check if the struct
syntax is valid. Then, it removes all attributes before using it for
output. `____cacheline_aligned_in_smp` is an attribute that is
not included in both steps. Add it, since it is used by kernel structs.
Signed-off-by: André Almeida <andrealmeid@collabora.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-3-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
André Almeida [Tue, 17 Nov 2020 16:52:44 +0000 (17:52 +0100)]
kernel-doc: fix processing nested structs with attributes
The current regular expression for strip attributes of structs (and
for nested ones as well) also removes all whitespaces that may
surround the attribute. After that, the code will split structs and
iterate for each symbol separated by comma at the end of struct
definition (e.g. "} alias1, alias2;"). However, if the nested struct
does not have any alias and has an attribute, it will result in a
empty string at the closing bracket (e.g "};"). This will make the
split return nothing and $newmember will keep uninitialized. Fix
that, by ensuring that the attribute substitution will leave at least
one whitespace.
Signed-off-by: André Almeida <andrealmeid@collabora.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20201117165312.118257-2-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>