[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] ac19b5: Add qemu qcode support for keys F13 t
|
From: |
Peter Maydell |
|
Subject: |
[Qemu-commits] [qemu/qemu] ac19b5: Add qemu qcode support for keys F13 to F24 |
|
Date: |
Thu, 16 Mar 2023 02:26:14 -0700 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: ac19b51678bd8e45ca2e44c062e4191bf8c48505
https://github.com/qemu/qemu/commit/ac19b51678bd8e45ca2e44c062e4191bf8c48505
Author: Willem van de Velde <williamvdvelde@gmail.com>
Date: 2023-03-14 (Tue, 14 Mar 2023)
Changed paths:
M qapi/ui.json
M ui/keycodemapdb
Log Message:
-----------
Add qemu qcode support for keys F13 to F24
To be able to use the function keys F13 to F24 these should be defined in de
keycodemapdb and added to the qapi.
The keycodemapdb is updated in its own repository, this patch enables the use
of those keys within qemu.
Signed-off-by: Willem van de Velde <williamvdvelde@gmail.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Commit: 92f4a21d912cd4618a2951c645b3d27d3c8a6b21
https://github.com/qemu/qemu/commit/92f4a21d912cd4618a2951c645b3d27d3c8a6b21
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date: 2023-03-14 (Tue, 14 Mar 2023)
Changed paths:
M hw/input/ps2.c
Log Message:
-----------
ps2: Don't send key release event for Lang1, Lang2 keys
The scancodes for the Lang1 and Lang2 keys (i.e. Hangeul, Hanja) are
special since they already have the 0x80 bit set which is commonly used
to indicate a key release in AT set 1. Reportedly, real hardware does
not send a key release scancode. So, skip sending a release for these
keys. This ensures that Windows behaves correctly and interprets it as a
single keypress rather than two consecutive keypresses.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Commit: c3a2c84ae3c1d5483ec30731321a674797dc5203
https://github.com/qemu/qemu/commit/c3a2c84ae3c1d5483ec30731321a674797dc5203
Author: Matheus Tavares Bernardino <quic_mathbern@quicinc.com>
Date: 2023-03-14 (Tue, 14 Mar 2023)
Changed paths:
M io/channel-tls.c
Log Message:
-----------
io/channel-tls: plug memory leakage on GSource
This leakage can be seen through test-io-channel-tls:
$ ../configure --target-list=aarch64-softmmu --enable-sanitizers
$ make ./tests/unit/test-io-channel-tls
$ ./tests/unit/test-io-channel-tls
Indirect leak of 104 byte(s) in 1 object(s) allocated from:
#0 0x7f81d1725808 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x7f81d135ae98 in g_malloc
(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98)
#2 0x55616c5d4c1b in object_new_with_propv ../qom/object.c:795
#3 0x55616c5d4a83 in object_new_with_props ../qom/object.c:768
#4 0x55616c5c5415 in test_tls_creds_create
../tests/unit/test-io-channel-tls.c:70
#5 0x55616c5c5a6b in test_io_channel_tls
../tests/unit/test-io-channel-tls.c:158
#6 0x7f81d137d58d (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7a58d)
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f81d1725a06 in __interceptor_calloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
#1 0x7f81d1472a20 in gnutls_dh_params_init
(/lib/x86_64-linux-gnu/libgnutls.so.30+0x46a20)
#2 0x55616c6485ff in qcrypto_tls_creds_x509_load
../crypto/tlscredsx509.c:634
#3 0x55616c648ba2 in qcrypto_tls_creds_x509_complete
../crypto/tlscredsx509.c:694
#4 0x55616c5e1fea in user_creatable_complete ../qom/object_interfaces.c:28
#5 0x55616c5d4c8c in object_new_with_propv ../qom/object.c:807
#6 0x55616c5d4a83 in object_new_with_props ../qom/object.c:768
#7 0x55616c5c5415 in test_tls_creds_create
../tests/unit/test-io-channel-tls.c:70
#8 0x55616c5c5a6b in test_io_channel_tls
../tests/unit/test-io-channel-tls.c:158
#9 0x7f81d137d58d (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7a58d)
...
SUMMARY: AddressSanitizer: 49143 byte(s) leaked in 184 allocation(s).
The docs for `g_source_add_child_source(source, child_source)` says
"source will hold a reference on child_source while child_source is
attached to it." Therefore, we should unreference the child source at
`qio_channel_tls_read_watch()` after attaching it to `source`. With this
change, ./tests/unit/test-io-channel-tls shows no leakages.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Matheus Tavares Bernardino <quic_mathbern@quicinc.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Commit: ddc7cb30f824a7062974c017154b9c0dc2a059aa
https://github.com/qemu/qemu/commit/ddc7cb30f824a7062974c017154b9c0dc2a059aa
Author: Miroslav Rezanina <mrezanin@redhat.com>
Date: 2023-03-15 (Wed, 15 Mar 2023)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
Fix build without CONFIG_XEN_EMU
Upstream commit ddf0fd9ae1 "hw/xen: Support HVM_PARAM_CALLBACK_TYPE_GSI
callback"
added kvm_xen_maybe_deassert_callback usage to target/i386/kvm/kvm.c file
without
conditional preprocessing check. This breaks any build not using CONFIG_XEN_EMU.
Protect call by conditional preprocessing to allow build without CONFIG_XEN_EMU.
Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <20230308130557.2420-1-mrezanin@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit: 3b31669ea986575625cad4ee3dbe85bb3870b5c6
https://github.com/qemu/qemu/commit/3b31669ea986575625cad4ee3dbe85bb3870b5c6
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2023-03-15 (Wed, 15 Mar 2023)
Changed paths:
M docs/devel/atomics.rst
Log Message:
-----------
docs/devel: clarify further the semantics of RMW operations
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit: 54ad31fb0a0a54d3564f74a0e8dc8ef2b70d5611
https://github.com/qemu/qemu/commit/54ad31fb0a0a54d3564f74a0e8dc8ef2b70d5611
Author: David Woodhouse <dwmw2@infradead.org>
Date: 2023-03-15 (Wed, 15 Mar 2023)
Changed paths:
M hw/intc/ioapic.c
Log Message:
-----------
hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update
A Linux guest will perform IRQ migration after the IRQ has happened,
updating the RTE to point to the new destination CPU and then unmasking
the interrupt.
However, when the guest updates the RTE, ioapic_mem_write() calls
ioapic_service(), which redelivers the pending level interrupt via
kvm_set_irq(), *before* calling ioapic_update_kvm_routes() which sets
the new target CPU.
Thus, the IRQ which is supposed to go to the new target CPU is instead
misdelivered to the previous target. An example where the guest kernel
is attempting to migrate from CPU#2 to CPU#0 shows:
xenstore_read tx 0 path control/platform-feature-xs_reset_watches
ioapic_set_irq vector: 11 level: 1
ioapic_set_remote_irr set remote irr for pin 11
ioapic_service: trigger KVM IRQ 11
[ 0.523627] The affinity mask was 0-3 and the handler is on 2
ioapic_mem_write ioapic mem write addr 0x0 regsel: 0x27 size 0x4 val 0x26
ioapic_update_kvm_routes: update KVM route for IRQ 11: fee02000 8021
ioapic_mem_write ioapic mem write addr 0x10 regsel: 0x26 size 0x4 val 0x18021
xenstore_reset_watches
ioapic_set_irq vector: 11 level: 1
ioapic_mem_read ioapic mem read addr 0x10 regsel: 0x26 size 0x4 retval 0x1c021
[ 0.524569] ioapic_ack_level IRQ 11 moveit = 1
ioapic_eoi_broadcast EOI broadcast for vector 33
ioapic_clear_remote_irr clear remote irr for pin 11 vector 33
ioapic_mem_write ioapic mem write addr 0x0 regsel: 0x26 size 0x4 val 0x26
ioapic_mem_read ioapic mem read addr 0x10 regsel: 0x26 size 0x4 retval 0x18021
[ 0.525235] ioapic_finish_move IRQ 11 calls irq_move_masked_irq()
[ 0.526147] irq_do_set_affinity for IRQ 11, 0
[ 0.526732] ioapic_set_affinity for IRQ 11, 0
[ 0.527330] ioapic_setup_msg_from_msi for IRQ11 target 0
ioapic_mem_write ioapic mem write addr 0x0 regsel: 0x26 size 0x4 val 0x27
ioapic_mem_write ioapic mem write addr 0x10 regsel: 0x27 size 0x4 val 0x0
ioapic_mem_write ioapic mem write addr 0x0 regsel: 0x27 size 0x4 val 0x26
ioapic_mem_write ioapic mem write addr 0x10 regsel: 0x26 size 0x4 val 0x18021
[ 0.527623] ioapic_set_affinity returns 0
[ 0.527623] ioapic_finish_move IRQ 11 calls unmask_ioapic_irq()
ioapic_mem_write ioapic mem write addr 0x0 regsel: 0x26 size 0x4 val 0x26
ioapic_mem_write ioapic mem write addr 0x10 regsel: 0x26 size 0x4 val 0x8021
ioapic_set_remote_irr set remote irr for pin 11
ioapic_service: trigger KVM IRQ 11
ioapic_update_kvm_routes: update KVM route for IRQ 11: fee00000 8021
[ 0.529571] The affinity mask was 0 and the handler is on 2
[ xenstore_watch path memory/target token FFFFFFFF92847D40
There are no other code paths in ioapic_mem_write() which need the KVM
IRQ routing table to be updated, so just shift the call from the end
of the function to happen right before the call to ioapic_service()
and thus deliver the re-enabled IRQ to the right place.
Alternative fixes might have been just to remove the part in
ioapic_service() which delivers the IRQ via kvm_set_irq() because
surely delivering as MSI ought to work just fine anyway in all cases?
That code lacks a comment justifying its existence.
Or maybe in the specific case shown in the above log, it would have
sufficed for ioapic_update_kvm_routes() to update the route *even*
when the IRQ is masked. It's not like it's actually going to get
triggered unless QEMU deliberately does so, anyway? But that only
works because the target CPU happens to be in the high word of the
RTE; if something in the *low* word (vector, perhaps) was changed
at the same time as the unmask, we'd still trigger with stale data.
Fixes: 15eafc2e602f "kvm: x86: add support for KVM_CAP_SPLIT_IRQCHIP"
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20230308111952.2728440-2-dwmw2@infradead.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit: dee2a4d4d2f6adc3c664e37a559d4187deee4818
https://github.com/qemu/qemu/commit/dee2a4d4d2f6adc3c664e37a559d4187deee4818
Author: Fiona Ebner <f.ebner@proxmox.com>
Date: 2023-03-15 (Wed, 15 Mar 2023)
Changed paths:
M softmmu/vl.c
Log Message:
-----------
vl: defuse PID file path resolve error
Commit 85c4bf8aa6 ("vl: Unlink absolute PID file path") introduced a
critical error when the PID file path cannot be resolved. Before this
commit, it was possible to invoke QEMU when the PID file was a file
created with mkstemp that was already unlinked at the time of the
invocation. There might be other similar scenarios.
It should not be a critical error when the PID file unlink notifier
can't be registered, because the path can't be resolved. If the file
is already gone from QEMU's perspective, silently ignore the error.
Otherwise, only print a warning.
Fixes: 85c4bf8aa6 ("vl: Unlink absolute PID file path")
Reported-by: Dominik Csapak <d.csapak@proxmox.com>
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20221031094716.39786-1-f.ebner@proxmox.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit: be4033d76ec7b6bd7b3d274f876b8af583aec3a8
https://github.com/qemu/qemu/commit/be4033d76ec7b6bd7b3d274f876b8af583aec3a8
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2023-03-15 (Wed, 15 Mar 2023)
Changed paths:
M docs/devel/atomics.rst
M hw/intc/ioapic.c
M softmmu/vl.c
M target/i386/kvm/kvm.c
Log Message:
-----------
Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
small bug fixes
# -----BEGIN PGP SIGNATURE-----
#
# iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmQRo3EUHHBib256aW5p
# QHJlZGhhdC5jb20ACgkQv/vSX3jHroO7wwgAp2IGW9TDAElFgPZ3n8XyoJ6Lnr6i
# Le3L+fQbYuy6uCU7zkboWgFqqNRLkd1nxHPkRgxb5oJ8pnXLCrdG+2d9UDgfMFqZ
# 3ankE+De70j7f7r0M5Ifmfyf7QHhNhnbuguoovi6S9bdJ5aO2nZmsm/T41Bth/uU
# SKx+SCVMzpPGLJv0iZishw2seZj0h9QBgyitsE8MdLjnhe5KD4XOWs4+E263pb6L
# G6ai7T++vQSRqCQ8YVBr7Az41vkvzuqkybAXFTl/QLd2rVQROAqoOpn+wPq4cH46
# xf6LscXqE9lrWr/UJnDPNiyKmsY5baLyB6Ri/rQn8VvTyfyHC9JtDoDclQ==
# =mnvI
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 15 Mar 2023 10:52:33 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
* tag 'for-upstream' of https://gitlab.com/bonzini/qemu:
vl: defuse PID file path resolve error
hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update
docs/devel: clarify further the semantics of RMW operations
Fix build without CONFIG_XEN_EMU
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit: 9636e513255362c4a329e3e5fb2c97dab3c5ce47
https://github.com/qemu/qemu/commit/9636e513255362c4a329e3e5fb2c97dab3c5ce47
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2023-03-15 (Wed, 15 Mar 2023)
Changed paths:
M hw/input/ps2.c
M io/channel-tls.c
M qapi/ui.json
M ui/keycodemapdb
Log Message:
-----------
Merge tag 'misc-next-pull-request' of https://gitlab.com/berrange/qemu into
staging
Miscellaneous fixes
* Avoid memory leak in TLS GSource usage
* Avoid sending key releases for lang1/lang2 keys in ps2 keyboard
* Add missing key name constants for F13-F24 keys
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE2vOm/bJrYpEtDo4/vobrtBUQT98FAmQQn/gACgkQvobrtBUQ
# T9+BxRAAl1aOI2rHW27vnwX4xGJX4y4ENA4GAWrnGfya+Ewcoze544W3jwT8b94b
# KDY62P+NMrlxWMjYlDb8if+TYjXc5orlJFBl94zmbaIS7vajnYmprqP3ipCHD/rw
# J5sTOrE8j4+Q+SRQliSwozS+vFm74BoghSLNUBretjxoxZymkUtqKFC88eUFIXsZ
# prGpBVm9g22NWQ94YwJg4iqkAGm0iDjzNsDxHkYhg4yoAsfU800aoKZuSJft6Pfc
# PTQ+x2Y0rxoQ+YuFyf7/uGK7w7awguMkeIn/Nalz3LcxzB+BFPby+P8Srp6WABD5
# N8COb38L5XtN4UffiK1//lxdLFmbO6NVMOaE1yUcG6CAOZNC4eZLIIEDEbvGWOm5
# f2h/YRK59F4HEbYazimEMxqa2SKBGV7j2nvqUEERyNo++U6WLR2toZPlRYP0EWgK
# YuLNGKr4XwNZXmAUO36YglMCowXHUwQdITU+gZt4QIcrjEEAeG9U3pspwyfGcYQl
# 3zd/xzeHGJQHzXNBnyRX0OQamE1et+UGqGauFYAVKFcHHq5VIe5W3BDBLj57DvQn
# T+tZBA92esPl9/qHx0zFfSfiSDHvs67obHPp4LcrNENUXtJOVoqOxpAUtQ9aBX8J
# jhPpkqBrMHtpyjMSM9xyjstro8pD47Kt6t930Sp9fh7fOjO0awE=
# =lL/5
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 14 Mar 2023 16:25:28 GMT
# gpg: using RSA key DAF3A6FDB26B62912D0E8E3FBE86EBB415104FDF
# gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>" [full]
# gpg: aka "Daniel P. Berrange <berrange@redhat.com>" [full]
# Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF
* tag 'misc-next-pull-request' of https://gitlab.com/berrange/qemu:
io/channel-tls: plug memory leakage on GSource
ps2: Don't send key release event for Lang1, Lang2 keys
Add qemu qcode support for keys F13 to F24
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Compare: https://github.com/qemu/qemu/compare/652737c8090e...9636e5132553