fw_cfg_arch_key_name() stub is only required for sysemu.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <20220111184309.28637-2-f4bug@amsat.org>
We should only call the log_global_start/stop when the global dirty track
bitmask changes from zero<->non-zero.
No real issue reported for this yet probably because no immediate user to
enable both dirty rate measurement and migration at the same time. However
it'll be good to be prepared for it.
Fixes: 63b41db4bc ("memory: make global_dirty_tracking a bitmask")
Cc: qemu-stable@nongnu.org
Cc: Hyman Huang <huangy81@chinatelecom.cn>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>
Cc: David Hildenbrand <david@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211130080028.6474-1-peterx@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Let's update the documentation, making it clearer what the semantics
of memory_region_is_mapped() actually are.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211102164317.45658-4-david@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
memory_region_is_mapped() currently does not return "true" when a memory
region is mapped via an alias.
Assuming we have:
alias (A0) -> alias (A1) -> region (R0)
Mapping A0 would currently only make memory_region_is_mapped() succeed
on A0, but not on A1 and R0.
Let's fix that by adding a "mapped_via_alias" counter to memory regions and
updating it accordingly when an alias gets (un)mapped.
I am not aware of actual issues, this is rather a cleanup to make it
consistent.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211102164317.45658-3-david@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
memory_region_is_mapped() is the wrong check, we actually want to check
whether the backend is already marked mapped.
For example, memory regions mapped via an alias, such as NVDIMMs,
currently don't make memory_region_is_mapped() return "true". As the
machine is initialized before any memory devices (and thereby before
NVDIMMs are initialized), this isn't a fix but merely a cleanup.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211102164317.45658-2-david@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
While mtree_info() handles both ASes and flatviews cases,
the two cases share basically no code. Split mtree_info()
as mtree_info_flatview() + mtree_info_as() to simplify.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210904231101.1071929-2-philmd@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Since commit 2cdfcf272d ("memory: assign MemoryRegionOps to all
regions"), all newly created regions are assigned with
unassigned_mem_ops (which might be then overwritten).
When using aliased container regions, and there is no region mapped
at address 0 in the container, the memory_region_dispatch_read()
and memory_region_dispatch_write() calls incorrectly return the
container unassigned_mem_ops, because the alias offset is not used.
Consider the following setup:
+--------------------+ < - - - - - - - - - - - +
| Container | mr
| (unassigned_mem) | |
| |
| | |
| | alias_offset
+ + <- - - - - - +----------+---------+
| +----------------+ | | |
| | MemoryRegion0 | | | |
| +----------------+ | | Alias | addr1
| | MemoryRegion1 | | <~ ~ ~ ~ ~ | | <~~~~~~
| +----------------+ | | |
| | +--------------------+
| |
| |
| |
| |
| +----------------+ |
| | MemoryRegionX | |
| +----------------+ |
| | MemoryRegionY | |
| +----------------+ |
| | MemoryRegionZ | |
| +----------------+ |
+--------------------+
The memory_region_init_alias() flow is:
memory_region_init_alias()
-> memory_region_init()
-> object_initialize(TYPE_MEMORY_REGION)
-> memory_region_initfn()
-> mr->ops = &unassigned_mem_ops;
Later when accessing offset=addr1 via the alias, we expect to hit
MemoryRegion1. The memory_region_dispatch_read() flow is:
memory_region_dispatch_read(addr1)
-> memory_region_access_valid(mr) <- addr1 offset is ignored
-> mr->ops->valid.accepts()
-> unassigned_mem_accepts()
<- false
<- false
<- MEMTX_DECODE_ERROR
The caller gets a MEMTX_DECODE_ERROR while the access is OK.
Fix by dispatching aliases recursively, accessing its origin region
after adding the alias offset.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20210418055708.820980-1-f4bug@amsat.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEwsLBCepDxjwUI+uE711egWG6hOcFAmHjRNEACgkQ711egWG6
hOeLaQ/+IwvZEaf98SdzG+v0U/e88kfC5dnsRQPywnsmr9gHTIHxcOA7tcfrCVE3
s1odyoe1tzypVetNTIW0enguGxB2d0ifr1BloBx5rrRxa8NwIDMOOTW5TnvHZaay
zD4Z+5cZr9miD2Al4Wojoni7C0HAwnFsXOzMBzAgT7LLx7hdNrCU2q/YNhwsI+UK
2kZPPNfzF2rsFgo3IiyCHG+C6fWdTXHWeNXd5VdFpfnC7x70Z4HtB68ohIx7nMjS
LkvXDMNDycoNdLsDJTPDsNOV1GvsvBFeRyD5dXThDAgUlZVIaQPy1tbZ3jeenFoT
UoJqB+WCZx1mHtYagLufBs8AU+oF1vZ35vS9Ncq6VeCDw4Qb6883q+bjyDf0PH3J
HRXoFs7gejjqs1NP5yeqX7e687f/+FZkJsqhZucQFIl5Ped8JmBYTpjLQChf3yq1
ssUrIHVmCwg0nQivVPpDzh+z1XSlOUVF0nYb2iP2VoztAh6AZYt8hnp8xaI0EyNR
BJXBqNKnmpdY3IJRnkLK6q3OgYah/7EtuMj9E82jcc/NRasMXeQmUZDqfPDFxLu7
l7pDOYc+1/GJQBYOokSlHcmmWlbfyf+2TKReoqb0XryEXa9kTomlMDxBQ//LjEP8
DGzIzvI3l4P5CUZ6WCHLCLsGFp39H9ryWdYzRyeEN3Oi12SRa+o=
=US9k
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/konstantin/tags/qga-win32-pull-2022-01-10' into staging
[PULL 0/9] qemu-ga-win patches
# gpg: Signature made Sat 15 Jan 2022 22:04:01 GMT
# gpg: using RSA key C2C2C109EA43C63C1423EB84EF5D5E8161BA84E7
# gpg: Good signature from "Kostiantyn Kostiuk (Upstream PR sign) <kkostiuk@redhat.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: C2C2 C109 EA43 C63C 1423 EB84 EF5D 5E81 61BA 84E7
* remotes/konstantin/tags/qga-win32-pull-2022-01-10:
qga-win: Detect Windows 11 by build number
qga-win: Detect OS based on Windows 10 by first build number
gqa-win: get_pci_info: Replace 'while' with 2 calls of the function
gqa-win: get_pci_info: Add g_autofree for few variables
gqa-win: get_pci_info: Split logic to separate functions
gqa-win: get_pci_info: Free parent_dev_info properly
gqa-win: get_pci_info: Use common 'end' label
gqa-win: get_pci_info: Clean dev_info if handle is valid
MAINTAINERS: Add entry for QEMU Guest Agent Windows components
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
A lot of Optional[] types doesn't make code beautiful.
test_field_width defaults to 8, but that is never used in the code.
More over, if we want some default behavior for single call of
test_run(), it should just print the whole test name, not limiting or
expanding its width, so 8 is bad default.
So, just drop the default as unused for now.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211210201450.101576-1-vsementsov@virtuozzo.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
First, this permission never protected a node from being changed, as
generic child-replacing functions don't check it.
Second, it's a strange thing: it presents a permission of parent node
to change its child. But generally, children are replaced by different
mechanisms, like jobs or qmp commands, not by nodes.
Graph-mod permission is hard to understand. All other permissions
describe operations which done by parent node on its child: read,
write, resize. Graph modification operations are something completely
different.
The only place where BLK_PERM_GRAPH_MOD is used as "perm" (not shared
perm) is mirror_start_job, for s->target. Still modern code should use
bdrv_freeze_backing_chain() to protect from graph modification, if we
don't do it somewhere it may be considered as a bug. So, it's a bit
risky to drop GRAPH_MOD, and analyzing of possible loss of protection
is hard. But one day we should do it, let's do it now.
One more bit of information is that locking the corresponding byte in
file-posix doesn't make sense at all.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20210902093754.2352-1-vsementsov@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Consider the case when the whole buffer is zero and end is unaligned.
If i <= tail, we return 1 and do one unaligned WRITE, RMW happens.
If i > tail, we do on aligned WRITE_ZERO (or skip if target is zeroed)
and again one unaligned WRITE, RMW happens.
Let's do better: don't fragment the whole-zero buffer and report it as
ZERO: in case of zeroed target we just do nothing and avoid RMW. If
target is not zeroes, one unaligned WRITE_ZERO should not be much worse
than one unaligned WRITE.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211217164654.1184218-3-vsementsov@virtuozzo.com>
Tested-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
This demonstrates what happens when the block status changes in
sub-min_sparse granularity, but all of the parts are zeroed out. The
alignment logic in is_allocated_sectors() prevents that the target image
remains fully sparse as expected, but turns it into a data cluster of
explicit zeros.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211217164654.1184218-2-vsementsov@virtuozzo.com>
Tested-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The calculation in sector2cluster() is done relative to the offset of
the root directory. Any writes to blocks before the start of the root
directory (in particular, writes to the FAT) result in negative values,
which are not handled correctly in vvfat_write().
This changes sector2cluster() to return a signed value, and makes sure
that vvfat_write() doesn't try to find mappings for negative cluster
number. It clarifies the code in vvfat_write() to make it more obvious
that the cluster numbers can be negative.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20211209152231.23756-1-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The size of the qcow size was calculated so that only the FAT partition
would fit on it, but not the whole disk. However, offsets relative to
the whole disk are used to access it, so increase its size to be large
enough for that.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20211209151815.23495-1-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
With CAP_DAC_OVERRIDE (which e.g. root generally has), permission checks
will be bypassed when opening files.
308 in one instance tries to open a read-only file (FUSE export) with
qemu-io as read/write, and expects this to fail. However, when running
it as root, opening will succeed (thanks to CAP_DAC_OVERRIDE) and only
the actual write operation will fail.
Note this as "Case not run", but have the test pass in either case.
Reported-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Fixes: 2c7dd057aa
("export/fuse: Pass default_permissions for mount")
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220103120014.13061-1-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Test the following scenario:
- Simple stream block in two-layer backing chain (base and top)
- The job is drained via blk_drain(), then an error occurs while the job
settles the ongoing request
- And so the job completes while in blk_drain()
This was reported as a segfault, but is fixed by "block-backend: prevent
dangling BDS pointers across aio_poll()".
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2036178
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20220111153613.25453-3-stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The BlockBackend root child can change when aio_poll() is invoked. This
happens when a temporary filter node is removed upon blockjob
completion, for example.
Functions in block/block-backend.c must be aware of this when using a
blk_bs() pointer across aio_poll() because the BlockDriverState refcnt
may reach 0, resulting in a stale pointer.
One example is scsi_device_purge_requests(), which calls blk_drain() to
wait for in-flight requests to cancel. If the backup blockjob is active,
then the BlockBackend root child is a temporary filter BDS owned by the
blockjob. The blockjob can complete during bdrv_drained_begin() and the
last reference to the BDS is released when the temporary filter node is
removed. This results in a use-after-free when blk_drain() calls
bdrv_drained_end(bs) on the dangling pointer.
Explicitly hold a reference to bs across block APIs that invoke
aio_poll().
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2021778
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2036178
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20220111153613.25453-2-stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
When building QEMU with --disable-vhost-user and using introspection,
query-qmp-schema lists vhost-user-blk even though it's not actually
available:
{ "execute": "query-qmp-schema" }
{
"return": [
...
{
"name": "312",
"members": [
{
"name": "nbd"
},
{
"name": "vhost-user-blk"
}
],
"meta-type": "enum",
"values": [
"nbd",
"vhost-user-blk"
]
},
Restrict vhost-user-blk in BlockExportType when
CONFIG_VHOST_USER_BLK_SERVER is disabled, so it
doesn't end listed by query-qmp-schema.
Fixes: 90fc91d50b ("convert vhost-user-blk server to block export API")
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220107105420.395011-4-f4bug@amsat.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Add missing vhost-user-blk help:
$ qemu-storage-daemon -h
...
--export [type=]vhost-user-blk,id=<id>,node-name=<node-name>,
addr.type=unix,addr.path=<socket-path>[,writable=on|off]
[,logical-block-size=<block-size>][,num-queues=<num-queues>]
export the specified block node as a
vhosts-user-blk device over UNIX domain socket
--export [type=]vhost-user-blk,id=<id>,node-name=<node-name>,
fd,addr.str=<fd>[,writable=on|off]
[,logical-block-size=<block-size>][,num-queues=<num-queues>]
export the specified block node as a
vhosts-user-blk device over file descriptor
...
Fixes: 90fc91d50b ("convert vhost-user-blk server to block export API")
Reported-by: Qing Wang <qinwang@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220107105420.395011-3-f4bug@amsat.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reported-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220107105420.395011-2-f4bug@amsat.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The -device JSON syntax impl leaks a reference on the created
DeviceState instance. As a result when you hot-unplug the
device, the device_finalize method won't be called and thus
it will fail to emit the required DEVICE_DELETED event.
A 'json-cli' feature was previously added against the
'device_add' QMP command QAPI schema to indicated to mgmt
apps that -device supported JSON syntax. Given the hotplug
bug that feature flag is not usable for its purpose, so
we add a new 'json-cli-hotplug' feature to indicate the
-device supports JSON without breaking hotplug.
Fixes: 5dacda5167
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/802
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220105123847.4047954-2-berrange@redhat.com>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Tested-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Remove drive_get_max_devs, as it is not used by anyone.
Last use was removed in commit 8f2d75e81d
("hw: Drop superfluous special checks for orphaned -drive").
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20211215121140.456939-4-eesposit@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
drive_def is only a particular use case of
qemu_opts_parse_noisily, so it can be inlined.
Also remove drive_mark_claimed_by_board, as it is only defined
but not implemented (nor used) anywhere.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Message-Id: <20211215121140.456939-3-eesposit@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
bdrv_backing_overridden is only used in block.c, so there is
no need to leave it in block_int.h
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20211215121140.456939-2-eesposit@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
This code seems to be used by vmport hack, passing these values allows
to implement horizontal scroll support even when using vmport.
In case it's not supported horizontal scroll will act as a vertical one.
Signed-off-by: Dmitry Petrov <dpetroff@gmail.com>
Message-Id: <20220108153947.171861-6-dpetroff@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This change adds support for horizontal scroll to ps/2 mouse device
code. The code is implemented to match the logic of linux kernel
which is used as a reference.
Signed-off-by: Dmitry Petrov <dpetroff@gmail.com>
Message-Id: <20220108153947.171861-2-dpetroff@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* KVM_GET/SET_SREGS2 support for x86
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmHe0v8UHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroPPgQf/Usiph4SA/MjpqwmLP8ZL64ghWzUm
ZjZRRDC12cApBE/P7/TdzHGwx6IiRu2hWt3wVLFWWEpN7xNwoelrhgLZcr8Dl80P
1b2Pe/BHe1xXI+xC/BgK4qt8sxhSvb9hdFwgz2J4mPSgN64d0sXszm/r56rJ/PXq
T2/M/o6wyFexPhYMQcN/ssQIeQzL8uXTifd7GqpcfRM4iivW1KAFVv9zr+SWqE+7
QavIoRTpBiAb7r0EtuxLrPdgiqkx0OKXE93mwrjM0Anci33hdVHLqe8Zs4gmRzyM
sLqArJwG/kdy2fL8Pc3ncPOxKsBgXDIqfucAJ8Tong1hwLJXiyZnJTxMSg==
=Q2aI
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into staging
* configure and meson cleanups
* KVM_GET/SET_SREGS2 support for x86
# gpg: Signature made Wed 12 Jan 2022 13:09:19 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:
meson: reenable filemonitor-inotify compilation
meson: build all modules by default
configure: do not create roms/seabios/config.mak if SeaBIOS not present
tests/tcg: Fix target-specific Makefile variables path for user-mode
KVM: x86: ignore interrupt_bitmap field of KVM_GET/SET_SREGS
KVM: use KVM_{GET|SET}_SREGS2 when supported.
meson: add comments in the target-specific flags section
configure, meson: move config-poison.h to meson
meson: build contrib/ executables after generated headers
configure: move non-command-line variables away from command-line parsing section
configure: parse --enable/--disable-strip automatically, flip default
configure, makefile: remove traces of really old files
configure: do not set bsd_user/linux_user early
configure: simplify creation of plugin symbol list
block/file-posix: Simplify the XFS_IOC_DIOINFO handling
meson: cleanup common-user/ build
user: move common-user includes to a subdirectory of {bsd,linux}-user/
meson: reuse common_user_inc when building files specific to user-mode emulators
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* New SLOF for PPC970 and POWER5+ (Alexey)
* Fixes for POWER5+ pseries (Cedric)
* Updates of documentation (Leonardo and Thomas)
* First step of exception model cleanup (Fabiano)
* User created PHB3/PHB4 devices (Daniel and Cedric)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmHesMkACgkQUaNDx8/7
7KG7LQ//bhaWJXgzhQcGc49QhNh2SCQjeqfnuwzlxthcIQ1YZpocOefGW3OZLksy
HEbbJ1dfWBm4bJa23YFf2OFpsLtBfSzg0W0o3m/9+Ufe5dXwae/MnMQoG/pNU+v2
gDk9179iORyDCk8dR28qQYYSz1AS0c+n0M7FCkcOF1vVklUWWV+2DMNEzagWkFDf
Ggu6X3MaIZAigvIOFKmny5AYqcRLF/OYHazDPe0I1XLM4GvrlO4Jy5Gz+RPtXtGN
sEFE+w0EifdwfXxsf2N3ecgWqOlfQt6N2wWGLp2YGwB0ro38L5/BuZTuaWnF1C4N
bu0dxGIhufYN5fvEc3SM3Jyx0agLRyQR3FQmNim92B9TWtJQ8cG+JZ7rbrMMhxt6
+KifMCqsDVV4eK2NSPTN++Fu5htoHotJqwkr1ajQriStX2Ihkr4hj3Yp4S724Ogn
U6LuYpB/bcrYeaEKBjPJXt4WgGy+nAp5Ije88BY9KXcw/5ZGIlAtTQ/HQ1HRWChN
CwlfBK0DZX83YJYsjZ3/k59HnpOsG2sOI3gSbG4cUiws7sFRuToEA9cThNY+d/Vr
Phx8bRijRTqa2nRYdxEM0z3vqjldkyMU4n7LzChqUJucwkfmLscdDZVTfRjV+ete
uLLqU6Y/ELMVKCRh8GRtmL/nHMulCzmoDLuKwJqmwBHeUS9BkBM=
=H+2M
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/legoater/tags/pull-ppc-20220112' into staging
ppc 7.0 queue:
* New SLOF for PPC970 and POWER5+ (Alexey)
* Fixes for POWER5+ pseries (Cedric)
* Updates of documentation (Leonardo and Thomas)
* First step of exception model cleanup (Fabiano)
* User created PHB3/PHB4 devices (Daniel and Cedric)
# gpg: Signature made Wed 12 Jan 2022 10:43:21 GMT
# gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1
# gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [undefined]
# 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: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1
* remotes/legoater/tags/pull-ppc-20220112: (34 commits)
ppc/pnv: use stack->pci_regs[] in pnv_pec_stk_pci_xscom_write()
ppc/pnv: turn pnv_phb4_update_regions() into static
ppc/pnv: Introduce user creatable pnv-phb4 devices
ppc/pnv: turn 'phb' into a pointer in struct PnvPhb4PecStack
ppc/pnv: move PHB4 XSCOM init to phb4_realize()
ppc/pnv: set phb4 properties in stk_realize()
pnv_phb4_pec: use pnv_phb4_pec_get_phb_id() in pnv_pec_dt_xscom()
pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.c
pnv_phb4.c: change TYPE_PNV_PHB4_ROOT_BUS name
pnv_phb3.h: change TYPE_PNV_PHB3_ROOT_BUS name
ppc/pnv: Move num_phbs under Pnv8Chip
ppc/pnv: Complete user created PHB3 devices
ppc/pnv: Reparent user created PHB3 devices to the PnvChip
ppc/pnv: Introduce support for user created PHB3 devices
pnv_phb4.c: check if root port exists in rc_config functions
pnv_phb4.c: make pnv-phb4-root-port user creatable
ppc/pnv: Attach PHB3 root port device when defaults are enabled
pnv_phb4.c: add unique chassis and slot for pnv_phb4_root_port
pnv_phb3.c: add unique chassis and slot for pnv_phb3_root_port
target/ppc: Set the correct endianness for powernv memory dumps
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Previously, the large modes (>1080p) that were generated by Qemu in its EDID
were all 50 Hz. If we provide them to a Guest OS and the user selects
one of these modes, then the OS by default only gets 50 FPS. This is
especially true for Windows OS. With this patch, we are now exposing a
3840x2160@60 Hz which will allow the guest OS to get 60 FPS.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Satyeshwar Singh <satyeshwar.singh@intel.com>
Message-Id: <20211116221103.27128-1-dongwon.kim@intel.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently QEMU defaults to a resolution of 1024x768 when exposing EDID
info to the guest OS. The EDID default info is important as this will
influence what resolution many guest OS will configure the screen with
on boot. It can also potentially influence what resolution the firmware
will configure the screen with, though until very recently EDK2 would
not handle EDID info.
One important thing to bear in mind is that the default graphics card
driver provided by Windows will leave the display set to whatever
resolution was enabled by the firmware on boot. Even if sufficient
VRAM is available, the resolution can't be changed without installing
new drivers. IOW, the default resolution choice is quite important
for usability of Windows.
Modern real world monitor hardware for desktop/laptop has supported
resolutions higher than 1024x768 for a long time now, perhaps as long
as 15+ years. There are quite a wide variety of native resolutions in
use today, however, and in wide screen form factors the height may not
be all that tall.
None the less, it is considered that there is scope for making the
QEMU default resolution slightly larger.
In considering what possible new default could be suitable, choices
considered were 1280x720 (720p), 1280x800 (WXGA) and 1280x1024 (SXGA).
In many ways, vertical space is the most important, and so 720p was
discarded due to loosing vertical space, despite being 25% wider.
The SXGA resolution would be good, but when taking into account
window titlebars/toolbars and window manager desktop UI, this might
be a little too tall for some users to fit the guest on their physical
montior.
This patch thus suggests a modest change to 1280x800 (WXGA). This
only consumes 1 MB per colour channel, allowing double buffered
framebuffer in 8 MB of VRAM. Width wise this is 25% larger than
QEMU's current default, but height wise this only adds 5%, so the
difference isn't massive on the QEMU side.
Overall there doesn't appear to be a compelling reason to stick
with 1024x768 resolution.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20211129140508.1745130-1-berrange@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
vga_mmio_init() is used only one time and not very helpful,
inline and remove it.
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20211206224528.563588-5-f4bug@amsat.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Introduce TYPE_VGA_MMIO, a sysbus device.
While there is no change in the vga_mmio_init()
interface, this is a migration compatibility break
of the MIPS Acer Pica 61 Jazz machine (pica61).
Suggested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20211206224528.563588-4-f4bug@amsat.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Inline vga_mm_init() in vga_mmio_init() to simplify the
next patch review. Kind of.
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211206224528.563588-3-f4bug@amsat.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
There is no ISA bus part in the MMIO VGA device, so rename:
* hw/display/vga-isa-mm.c -> hw/display/vga-mmio.c
* CONFIG_VGA_ISA_MM -> CONFIG_VGA_MMIO
* ISAVGAMMState -> VGAMmioState
* isa_vga_mm_init() -> vga_mmio_init()
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211206224528.563588-2-f4bug@amsat.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Otherwise we run the error handling code even for successful requests.
Fixes: 13b250b12a ("uas: add stream number sanity checks.")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20211210080659.2537084-1-kraxel@redhat.com>
When closing the QEMU Gtk display window, it can occasionaly warn:
qemu-system-x86_64: Gtk: gtk_clipboard_set_with_data: assertion 'targets != NULL' failed
#3 0x00007ffff4f02f22 in gtk_clipboard_set_with_data (clipboard=<optimized out>, targets=<optimized out>, n_targets=<optimized out>, get_func=<optimized out>, clear_func=<optimized out>, user_data=<optimized out>) at /usr/src/debug/gtk3-3.24.30-4.fc35.x86_64/gtk/gtkclipboard.c:672
#4 0x00007ffff552cd75 in gd_clipboard_update_info (gd=0x5555579a9e00, info=0x555557ba4b50) at ../ui/gtk-clipboard.c:98
#5 0x00007ffff552ce00 in gd_clipboard_notify (notifier=0x5555579aaba8, data=0x7fffffffd720) at ../ui/gtk-clipboard.c:128
#6 0x000055555603e0ff in notifier_list_notify (list=0x555556657470 <clipboard_notifiers>, data=0x7fffffffd720) at ../util/notify.c:39
#7 0x000055555594e8e0 in qemu_clipboard_update (info=0x555557ba4b50) at ../ui/clipboard.c:54
#8 0x000055555594e840 in qemu_clipboard_peer_release (peer=0x55555684a5b0, selection=QEMU_CLIPBOARD_SELECTION_PRIMARY) at ../ui/clipboard.c:40
#9 0x000055555594e786 in qemu_clipboard_peer_unregister (peer=0x55555684a5b0) at ../ui/clipboard.c:19
#10 0x000055555595f044 in vdagent_disconnect (vd=0x55555684a400) at ../ui/vdagent.c:852
#11 0x000055555595f262 in vdagent_chr_fini (obj=0x55555684a400) at ../ui/vdagent.c:908
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20211216083233.1166504-1-marcandre.lureau@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
On the last added dbus patch, I left a tiny BO:
==441487==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x611000025a70 at pc 0x7f0817bb764c bp 0x7ffde672ae60 sp 0x7ffde672ae58
WRITE of size 8 at 0x611000025a70 thread T0
#0 0x7f0817bb764b in dbus_vc_class_init ../ui/dbus.c:401
A cookie for ASAN! not you C :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Fixes: 7f767ca35e ("ui/dbus: register D-Bus VC handler")
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20211222144032.443424-1-marcandre.lureau@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Quote from:
High Definition Audio Specification 1.0a, section 3.3.35
Offset 80: {IOB}SDnCTL Stream Reset (SRST): Writing a 1 causes
the corresponding stream to be reset. The Stream Descriptor
registers (except the SRST bit itself) ... are reset.
Change the code to reset the Stream Descriptor Control and Status
registers except the SRST bit.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/757
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-Id: <20211226154017.6067-3-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Audio recordings with the DirectSound backend don't sound right.
A look a the Microsoft online documentation tells us why.
From the DirectSound Programming Guide, Capture Buffer Information:
'You can safely copy data from the buffer only up to the read
cursor.'
Change the code to read up to the read cursor instead of the
capture cursor.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-Id: <20211226154017.6067-2-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
On Windows the jack_set_thread_creator() function and on MacOS the
pthread_setname_np() function with a thread pointer paramater is
not available. Use #ifdefs to remove the jack_set_thread_creator()
function call and the qjack_thread_creator() function in both
cases.
The qjack_thread_creator() function just sets the name of the
created thread for debugging purposes and isn't really necessary.
From the jack_set_thread_creator() documentation:
(...)
No normal application/client should consider calling this. (...)
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/785
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <20211226154017.6067-1-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The GDB statck is as follows:
(gdb) bt
0 __lll_lock_wait (futex=futex@entry=0x56211df20360, private=0) at lowlevellock.c:52
1 0x00007f263caf20a3 in __GI___pthread_mutex_lock (mutex=0x56211df20360) at ../nptl/pthread_mutex_lock.c:80
2 0x000056211a757364 in qemu_mutex_lock_impl (mutex=0x56211df20360, file=0x56211a804857 "../ui/vnc-jobs.h", line=60)
at ../util/qemu-thread-posix.c:80
3 0x000056211a0ef8c7 in vnc_lock_output (vs=0x56211df14200) at ../ui/vnc-jobs.h:60
4 0x000056211a0efcb7 in vnc_clipboard_send (vs=0x56211df14200, count=1, dwords=0x7ffdf1701338) at ../ui/vnc-clipboard.c:138
5 0x000056211a0f0129 in vnc_clipboard_notify (notifier=0x56211df244c8, data=0x56211dd1bbf0) at ../ui/vnc-clipboard.c:209
6 0x000056211a75dde8 in notifier_list_notify (list=0x56211afa17d0 <clipboard_notifiers>, data=0x56211dd1bbf0) at ../util/notify.c:39
7 0x000056211a0bf0e6 in qemu_clipboard_update (info=0x56211dd1bbf0) at ../ui/clipboard.c:50
8 0x000056211a0bf05d in qemu_clipboard_peer_release (peer=0x56211df244c0, selection=QEMU_CLIPBOARD_SELECTION_CLIPBOARD)
at ../ui/clipboard.c:41
9 0x000056211a0bef9b in qemu_clipboard_peer_unregister (peer=0x56211df244c0) at ../ui/clipboard.c:19
10 0x000056211a0d45f3 in vnc_disconnect_finish (vs=0x56211df14200) at ../ui/vnc.c:1358
11 0x000056211a0d4c9d in vnc_client_read (vs=0x56211df14200) at ../ui/vnc.c:1611
12 0x000056211a0d4df8 in vnc_client_io (ioc=0x56211ce70690, condition=G_IO_IN, opaque=0x56211df14200) at ../ui/vnc.c:1649
13 0x000056211a5b976c in qio_channel_fd_source_dispatch
(source=0x56211ce50a00, callback=0x56211a0d4d71 <vnc_client_io>, user_data=0x56211df14200) at ../io/channel-watch.c:84
14 0x00007f263ccede8e in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
15 0x000056211a77d4a1 in glib_pollfds_poll () at ../util/main-loop.c:232
16 0x000056211a77d51f in os_host_main_loop_wait (timeout=958545) at ../util/main-loop.c:255
17 0x000056211a77d630 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:531
18 0x000056211a45bc8e in qemu_main_loop () at ../softmmu/runstate.c:726
19 0x000056211a0b45fa in main (argc=69, argv=0x7ffdf1701778, envp=0x7ffdf17019a8) at ../softmmu/main.c:50
From the call trace, we can see it is a deadlock bug.
vnc_disconnect_finish will acquire the output_mutex.
But, the output_mutex will be acquired again in vnc_clipboard_send.
Repeated locking will cause deadlock. So, I move
qemu_clipboard_peer_unregister() behind vnc_unlock_output();
Fixes: 0bf41cab93 ("ui/vnc: clipboard support")
Signed-off-by: Lei Rao <lei.rao@intel.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20220105020808.597325-1-lei.rao@intel.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
