Up to now, the finalize_gic_version() code open coded what is essentially
a support bitmap match between host/emulation environment and desired
target GIC type.
This open coding leads to undesirable side effects. For example, a VM with
KVM and -smp 10 will automatically choose GICv3 while the same command
line with TCG will stay on GICv2 and fail the launch.
This patch combines the TCG and KVM matching code paths by making
everything a 2 pass process. First, we determine which GIC versions the
current environment is able to support, then we go through a single
state machine to determine which target GIC mode that means for us.
After this patch, the only user noticable changes should be consolidated
error messages as well as TCG -M virt supporting -smp > 8 automatically.
Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Message-id: 20221223090107.98888-2-agraf@csgraf.de
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We currently only support GICv2 emulation. To also support GICv3, we will
need to pass a few system registers into their respective handler functions.
This patch adds support for HVF to call into the TCG callbacks for GICv3
system register handlers. This is safe because the GICv3 TCG code is generic
as long as we limit ourselves to EL0 and EL1 - which are the only modes
supported by HVF.
To make sure nobody trips over that, we also annotate callbacks that don't
work in HVF mode, such as EL state change hooks.
With GICv3 support in place, we can run with more than 8 vCPUs.
Signed-off-by: Alexander Graf <agraf@csgraf.de>
Message-id: 20230128224459.70676-1-agraf@csgraf.de
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Current FIFO handling code does not reset RXFE/RXFF flags when guest
resets FIFO by writing to UARTLCR register, although internal FIFO state
is reset to 0 read count. Actual guest-visible flag update will happen
only on next data read or write attempt. As a result of that any guest
that expects RXFE flag to be set (and RXFF to be cleared) after resetting
FIFO will never see that happen.
Signed-off-by: Evgeny Iakovlev <eiakovlev@linux.microsoft.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20230123162304.26254-5-eiakovlev@linux.microsoft.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
PL011 currently lacks a reset method. Implement it.
Signed-off-by: Evgeny Iakovlev <eiakovlev@linux.microsoft.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230123162304.26254-4-eiakovlev@linux.microsoft.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Previous change slightly modified the way we handle data writes when
FIFO is disabled. Previously we kept incrementing read_pos and were
storing data at that position, although we only have a
single-register-deep FIFO now. Then we changed it to always store data
at pos 0.
If guest disables FIFO and the proceeds to read data, it will work out
fine, because we still read from current read_pos before setting it to
0.
However, to make code less fragile, introduce a post_load hook for
PL011State and move fixup read FIFO state when FIFO is disabled. Since
we are introducing a post_load hook, also do some sanity checking on
untrusted incoming input state.
Signed-off-by: Evgeny Iakovlev <eiakovlev@linux.microsoft.com>
Message-id: 20230123162304.26254-3-eiakovlev@linux.microsoft.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
PL011 can be in either of 2 modes depending guest config: FIFO and
single register. The last mode could be viewed as a 1-element-deep FIFO.
Current code open-codes a bunch of depth-dependent logic. Refactor FIFO
depth handling code to isolate calculating current FIFO depth.
One functional (albeit guest-invisible) side-effect of this change is
that previously we would always increment s->read_pos in UARTDR read
handler even if FIFO was disabled, now we are limiting read_pos to not
exceed FIFO depth (read_pos itself is reset to 0 if user disables FIFO).
Signed-off-by: Evgeny Iakovlev <eiakovlev@linux.microsoft.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230123162304.26254-2-eiakovlev@linux.microsoft.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Use the macro instead of two explicit string literals.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20230124232059.4017615-1-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* Remove the deprecated OTP config of sifive_u
* Add libfdt to some of our CI jobs that were still missing it
* Use __builtin_bswap() everywhere (all compiler versions support it now)
* Deprecate the HAXM accelerator
* Document PCI devices handling on s390x
* Make Audiodev introspectable
* Improve the runtime of some CI jobs
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmPY59YRHHRodXRoQHJl
ZGhhdC5jb20ACgkQLtnXdP5wLbXzhxAAmoq2j2sbAf2Vr9tz6Ez2p9oKNYnzUEWb
NGXdvQMcVFKIdjvSYt5ozLC53OFIzuS74X7oHKbdLvGzez3nMCijZIbzN6vNnvd9
HNGum4blNwHEfQcY9hr9y30Iurc7CQu6VtwGF+XXdzQZDbPz1Z4AWvtPTLcTbkxa
PskYJfFvow/oaTHDA/7t+90cxCOixKvQMKXL5ATCtMRGnjlbOAEoPbXUB+yM24mk
9qp1L/8h8pvXfeXlFj+KETmu+eE5ETEOQtqc2KhQqqze2+VMKYxSX2H+sNkJBPDP
En8Mpy+fEdefu8Jcu+M2kMLhf1f3LVf9uARhLZY4/xmOYFg+F3xzwpshnH1bs+Kw
IzWP84uHjE77jSy/wKvYiCx2hdCDwO0G+zym67D1fPzvjzKzUNprV4OIuRzTWah3
6Zli5uuaLrBNjR8SJB1HDmLGKDFgToH9dzfLPtDmW8UPJGkAGcBbPKktLTe5y/4E
del99NqpTx5SAqMmbSMRPZ/vZ7ITdfB0Av3a0GdO8j7eSPb9BOsoZOVD2/iUzab/
P0dBuNqMM8fwywVKqcK+0CJ/npWIJvOqqlwSDqhY1A78G/uRuapOqUwsB/LWRFv5
/1VvHfA2rv4l9o66N5jssS5/D1v5p/UBB6JvlTUvuoJMFTXa9de9XFxYxfkyiaAz
LJl+Dh+aeWk=
=uq7y
-----END PGP SIGNATURE-----
Merge tag 'pull-request-2023-01-31' of https://gitlab.com/thuth/qemu into staging
* qtest improvements
* Remove the deprecated OTP config of sifive_u
* Add libfdt to some of our CI jobs that were still missing it
* Use __builtin_bswap() everywhere (all compiler versions support it now)
* Deprecate the HAXM accelerator
* Document PCI devices handling on s390x
* Make Audiodev introspectable
* Improve the runtime of some CI jobs
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmPY59YRHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbXzhxAAmoq2j2sbAf2Vr9tz6Ez2p9oKNYnzUEWb
# NGXdvQMcVFKIdjvSYt5ozLC53OFIzuS74X7oHKbdLvGzez3nMCijZIbzN6vNnvd9
# HNGum4blNwHEfQcY9hr9y30Iurc7CQu6VtwGF+XXdzQZDbPz1Z4AWvtPTLcTbkxa
# PskYJfFvow/oaTHDA/7t+90cxCOixKvQMKXL5ATCtMRGnjlbOAEoPbXUB+yM24mk
# 9qp1L/8h8pvXfeXlFj+KETmu+eE5ETEOQtqc2KhQqqze2+VMKYxSX2H+sNkJBPDP
# En8Mpy+fEdefu8Jcu+M2kMLhf1f3LVf9uARhLZY4/xmOYFg+F3xzwpshnH1bs+Kw
# IzWP84uHjE77jSy/wKvYiCx2hdCDwO0G+zym67D1fPzvjzKzUNprV4OIuRzTWah3
# 6Zli5uuaLrBNjR8SJB1HDmLGKDFgToH9dzfLPtDmW8UPJGkAGcBbPKktLTe5y/4E
# del99NqpTx5SAqMmbSMRPZ/vZ7ITdfB0Av3a0GdO8j7eSPb9BOsoZOVD2/iUzab/
# P0dBuNqMM8fwywVKqcK+0CJ/npWIJvOqqlwSDqhY1A78G/uRuapOqUwsB/LWRFv5
# /1VvHfA2rv4l9o66N5jssS5/D1v5p/UBB6JvlTUvuoJMFTXa9de9XFxYxfkyiaAz
# LJl+Dh+aeWk=
# =uq7y
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 31 Jan 2023 10:05:10 GMT
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5
* tag 'pull-request-2023-01-31' of https://gitlab.com/thuth/qemu: (27 commits)
gitlab-ci.d/buildtest: Merge the --without-default-* jobs
tests/qtest/display-vga-test: Add proper checks if a device is available
gitlab-ci.d/buildtest: Remove ppc-softmmu from the clang-system job
qapi, audio: Make introspection reflect build configuration more closely
qapi, audio: add query-audiodev command
docs/s390x/pcidevices: document pci devices on s390x
tests/qtest/boot-serial-test: Constify tests[] array
tests/qtest/vnc-display-test: Disable on Darwin
tests/qtest/vnc-display-test: Use the 'none' machine
tests/qtest/vnc-display-test: Suppress build warnings on Windows
tests/tcg: Do not build/run TCG tests if TCG is disabled
docs/about/deprecated: Mark HAXM in QEMU as deprecated
MAINTAINERS: Abort HAXM maintenance
qemu/bswap: Use compiler __builtin_bswap() on NetBSD
qemu/bswap: Use compiler __builtin_bswap() on FreeBSD
qemu/bswap: Use compiler __builtin_bswap() on Haiku
qemu/bswap: Remove <byteswap.h> dependency
qemu/bswap: Replace bswapXXs() by compiler __builtin_bswap()
qemu/bswap: Replace bswapXX() by compiler __builtin_bswap()
tests/docker/dockerfiles: Add libfdt to the i386 and to the riscv64 container
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This reverts commit a7f523c7d1.
The nested event loop is broken by design. It's only user was removed.
Drop the code as well so that nobody ever tries to use it again.
I had to fix a couple of trivial conflicts around return values because
of 025faa872b ("vhost-user: stick to -errno error return convention").
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <20230119172424.478268-3-groug@kaod.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
This reverts commit db8a3772e3.
Motivation : this is breaking vhost-user with DPDK as reported in [0].
Received unexpected msg type. Expected 22 received 40
Fail to update device iotlb
Received unexpected msg type. Expected 40 received 22
Received unexpected msg type. Expected 22 received 11
Fail to update device iotlb
Received unexpected msg type. Expected 11 received 22
vhost VQ 1 ring restore failed: -71: Protocol error (71)
Received unexpected msg type. Expected 22 received 11
Fail to update device iotlb
Received unexpected msg type. Expected 11 received 22
vhost VQ 0 ring restore failed: -71: Protocol error (71)
unable to start vhost net: 71: falling back on userspace virtio
The failing sequence that leads to the first error is :
- QEMU sends a VHOST_USER_GET_STATUS (40) request to DPDK on the master
socket
- QEMU starts a nested event loop in order to wait for the
VHOST_USER_GET_STATUS response and to be able to process messages from
the slave channel
- DPDK sends a couple of legitimate IOTLB miss messages on the slave
channel
- QEMU processes each IOTLB request and sends VHOST_USER_IOTLB_MSG (22)
updates on the master socket
- QEMU assumes to receive a response for the latest VHOST_USER_IOTLB_MSG
but it gets the response for the VHOST_USER_GET_STATUS instead
The subsequent errors have the same root cause : the nested event loop
breaks the order by design. It lures QEMU to expect responses to the
latest message sent on the master socket to arrive first.
Since this was only needed for DAX enablement which is still not merged
upstream, just drop the code for now. A working solution will have to
be merged later on. Likely protect the master socket with a mutex
and service the slave channel with a separate thread, as discussed with
Maxime in the mail thread below.
[0] https://lore.kernel.org/qemu-devel/43145ede-89dc-280e-b953-6a2b436de395@redhat.com/
Reported-by: Yanghang Liu <yanghliu@redhat.com>
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2155173
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <20230119172424.478268-2-groug@kaod.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Use the proper QOM type definition instead of magic string.
This also helps during eventual refactor while using git-grep.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230117193014.83502-1-philmd@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
The VHOST_USER_ADD/REM_MEM_REG requests should be categorized into
non-vring specific messages, and should be sent only once.
Signed-off-by: Minghao Yuan <yuanmh12@chinatelecom.cn>
Message-Id: <20230123122119.194347-1-yuanmh12@chinatelecom.cn>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Generating slots descriptions populated by non-hotpluggable devices
is akward at best and complicates hotplug path (build_append_pcihp_slots)
needlessly, and builds only dynamic _DSM for such slots which is overlkill.
Clean it up and let non-hotplug path (build_append_pci_bus_devices)
to handle that task.
Such clean up effectively drops dynamic _DSM methods on non-hotpluggable
slots (even though bus itself is hotpluggable), but in practice it
affects only built-in devices (ide controllers/various bridges) that don't
use acpi-index anyways so effectively it doesn't matter (NICs are hotpluggble).
Follow up series will add static _DSM for non-hotpluggble devices/buses
that will not depend on ACPI PCI hotplug at all, and potentially would
allows us to reuse non-hotplug path elsewhere (PBX/microvm/arm-virt),
including new support for acpi-index for non-hotpluggable devices.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-40-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
coldplugged bridges are not unpluggable, so there is no need
to describe slots where they are plugged as hotpluggable. To
that effect we have a condition that marks slot as non-hotpluggable
if it's populated by coldplugged bridge and prevents generation
_SUN/_EJ0 objects for it. That leaves dynamic _DSM method on
such slot (which also depends on BSEL and pcihp hardware).
This _DSM method provides only dynamic acpi-index support so far,
which is not actually used/supported by linux kernel for bridges
and it's doubtful there will be need for it at all.
So it's rather pointless to generate acpi-index related AML
for bridges and we can simplify hotplug slots generator a bit
more by completely ignoring coldplugged bridges on hotplug path.
Another point in favor of dropping dynamic _DSM support, is
that we can replace it with static _DSM if necessary since
a slot with bridge can't change during VM runtime and without
any dependency on ACPI PCI hotplug at that.
Later I plan to implement bridge specific static _DSM
PCI Firmware Specification 3.2
4.6.5. _DSM for Ignoring PCI Boot Configurations
part of spec, to fix longstanding issue with fixed IO/MEM
resource assignment that often leads to hotplugged device
being in-operational within the guest due limited IO/MEM
windows programmed on bridge at boot time.
Expected change when coldplugged bridge is ignored by hotplug
code, should look like:
- Scope (S18)
- {
- Name (ASUN, 0x03)
- Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
- {
- Local0 = Package (0x02)
- {
- BSEL,
- ASUN
- }
- Return (PDSM (Arg0, Arg1, Arg2, Arg3, Local0))
- }
- }
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-37-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Split build_append_pci_bus_devices() onto generic part that builds
AML descriptions only for populated slots which is applicable to
both hotplug disabled and enabled bridges. And a hotplug only
part that complements generic AML with hotplug depended bits
(that depend on BSEL), like _SUN/_EJ0 entries, dynamic _DSM.
Hotplug part, will generate full 'Device' descriptors for
non-populated slots (like it used to be) and complementary
'Scope' descriptors for populated slots that are hotplug capable.
i.e. something like this:
- ...
+ Name (BSEL, 0x03)
+ Scope (S00)
+ {
+ Name (ASUN, Zero)
+ Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
+ {
+ Local0 = Package (0x02)
+ {
+ BSEL,
+ ASUN
+ }
+ Return (PDSM (Arg0, Arg1, Arg2, Arg3, Local0))
+ }
+ [ ... other hotplug depended bits ]
+ }
While generic build_append_pci_bus_devices() still calls hotplug part at
its end it doesn't really depend on any hotplug bits anymore and later
both could be completely separated when it's necessary.
Main benefit though is that both build_append_pci_bus_devices() and
build_append_pcihp_slots() become more readable and it makes easier
to modify them with less risk of affecting another part. Also it opens
possibility to re-use generic part elsewhere (microvm, arm/virt).
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-34-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-32-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
function doesn't need RW aceess to passed in bus pointer,
make it const.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-31-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
simplify build_append_pci_bus_devices() a bit by handling bridge
specific logic in bridge dedicated AcpiDevAmlIfClass::build_dev_aml
callback.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-30-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
... so that the concrete impl. won't has to duplicate it
every time. By default it doesn't do anything unless leaf class
defines and sets AcpiDevAmlIfClass::build_dev_aml handler.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-29-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Before switching pci bridges to AcpiDevAmlIf interface, ensure that
ignored slots are handled correctly.
(existing rule works but only if bridge doesn't have AcpiDevAmlIf interface).
While at it rewrite related comments to be less confusing (hopefully).
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-28-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
count number of PCNT methods that actually call Notify
and if there aren't any, drop PCNT altogether.
It mostly affects 'Q35' tests where there is no root-ports
/bridges attached and 'PC' machine when ACPI PCI hotplug is
completely disabled.
Expected ASL change:
- Method (PCNT, 0, NotSerialized)
- {
- }
...
Method (_E01, 0, NotSerialized) // _Exx: Edge-Triggered GPE
{
- Acquire (\_SB.PCI0.BLCK, 0xFFFF)
- \_SB.PCI0.PCNT ()
- Release (\_SB.PCI0.BLCK)
}
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-23-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
it's a stepping stone to making build_append_pci_bus_devices() suitable
for AcpiDevAmlIfClass:build_dev_aml callback and lets further simplify
it by separating PCNT generation from slots descriptions.
It also makes PCNT callchain ASL much more readable since callchain
not longer cluttered by slots descriptors.
Plus, move will let next patch easily drop empty PCNT (pc/q35)
when there is nothing hotpluggable.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-22-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
.. and use only BSEL presence to decide on how PCNT should be composed.
That simplifies possible combinations to consider, but mainly it makes
PCIHP AML be governed only by BSEL, which is property of PCIBus
(aka part of bridge) and as result it opens possibility to convert
build_append_pci_bus_devices() into AcpiDevAmlIf::build_dev_aml
callback to make bridges self describing.
PS:
used approach leaves unused PCNT, when ACPI hotplug is completely
disabled but that's harmless and followup commits will get rid of
it later.
Scope (PCI0)
...
Method (PCNT, 0, NotSerialized)
{
}
...
}
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-19-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
When QEMU is started with hotplugged bridges (think migration):
QEMU -S -monitor stdio \
-device pci-bridge,chassis_nr=1 \
-device pci-bridge,bus=pci.1,addr=1.0,chassis_nr=2
(qemu) device_add pci-bridge,id=hpbr,bus=pci.1,addr=2.0,chassis_nr=3
(qemu) cont
it will generate AML calls to hpbr's PCNT, which doesn't exists
since it's hotplugged bridge. As result DSDT becomes malformed,
with consequences that hotplug might stop working at best or
crash guest OS at worst, when it attempts to call non existing
PCNT method or during OS guest reboot when parsing DSDT again.
IASL de-compiles malformed AML of above config DSDT as:
+ External (_SB_.PCI0.S18_.S10_.PCNT, MethodObj) // Warning: Unknown method, guessing 1 arguments
+ External (_SB_.PCI0.S18_.S19_.PCNT, MethodObj) // Warning: Unknown method, guessing 2 arguments
...
BNUM = One
DVNT (PCIU, One)
DVNT (PCID, 0x03)
- ^S08.PCNT ()
+ ^S19.PCNT (^S10.PCNT (^S08.PCNT ()))
}
}
With BSEL assignment limited only to coldplugged bridges [1],
it should be possible to add PCNT call to a child bridge only
if the child has BSEL property, otherwise ignore it since it's
hotplugged. Which should fix the issue.
1) ("pci: acpihp: assign BSEL only to coldplugged bridges")
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-13-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
ACPI PCI hotplug would broken after bridge hotplug and then migration
if hotplugged bridge were specified on target at command line.
Currently it's not possible since, 'hotplugged' property was made
read-only for some time now.
The issue would happen due to BSEL being assigned to all bridges
during 1st 'reset':
source seq:
1. start 'pc' machine => sets BSEL to 0 on pci.0 (host-bridge)
2. hotplug bridge, no bsel is assigned (so far is ok)
target seq:
1. start 'pc' machine with
-S -device pci-bridge,id=hp_br,hotplugged=on
BSEL gets assigned to as follows
hp_br: 0
pci.0: 1
as result hotplug requests with migrated AML generated on source
would be misdirected to 'hp_br' instead of intended pci.0
While it's not issue at the moment, it's based on implicit assumptions
* 'hotplugged' property is read-only
* 1st reset happens before QEMU drops into monitor mode
which lets add hotplugged on source bridges as hotplugged ones
(anything added at that stage counts as hotplugged
(yet another assumption))
All of it looks too fragile to me, so lets restrict BSEL only
to cold-plugged bridges explicitly.
Migration wise it shouldn't break anything since assignment order
stays the same:
* user can't specify 'hotplugged=on' on CLI
* user can't specify 'hotplugged=off' at monitor stage or later
on older QEMU versions where 'hotplugged' is RW, hotplug is broken
after migration anyways and we cannot do anything to fix that.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-12-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
piix4_pm_reset() is calling acpi_pcihp_reset() when ACPI PCI hotplug
is disabled, which leads to assigning BSEL properties to bridges on path
acpi_set_bsel()
...
if (qbus_is_hotpluggable(BUS(bus))) {
// above happens to be true by default (though it's SHPC hotplug handler)
// set BSEL
}
At the moment the issue is masked by the fact that we use not only BSEL,
to decide if we should generated hoplug AML but also pcihp_bridge_en knob.
However the later patches will drop dependency on pcihp_bridge_en,
and use only BSEL exclusively to decide if hotplug AML for slots should be built,
which exposes issue.
We should not ever call acpi_pcihp_reset() if ACPI PCI hotplug is disabled,
make it so.
PS:
* Q35 does the right thing (i.e. it calls acpi_pcihp_reset only when pcihp is enabled)
* the issue also makes acpi_pcihp_update() logic run on SHPC enabled bridges,
which seems to be harmless
Fixes: 3d7e78aa77 ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus")
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-11-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
When ACPI PCI hotplug for Q35 was introduced (6.1), it was implemented
by hiding HPC capability on PCIE slot. That however led to a number of
regressions and to fix it, it was decided to keep HPC cap exposed
in ACPI PCI hotplug case and force guest in ACPI PCI hotplug mode
by other means [1].
That reduced meaning of x-native-hotplug to a compat knob [2] for
broken 6.1 machine type.
Rename property to match its current purpose.
1) 211afe5c69 (hw/i386/acpi-build: Deny control on PCIe Native Hot-plug in _OSC)
2) c318bef762 (hw/acpi/ich9: Add compat prop to keep HPC bit set for 6.1 machine type)
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-10-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-9-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-8-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The setup_data links are appended to the compressed kernel image. Since
the kernel image is typically loaded at 0x100000, setup_data lives at
`0x100000 + compressed_size`, which does not get relocated during the
kernel's boot process.
The kernel typically decompresses the image starting at address
0x1000000 (note: there's one more zero there than the compressed image
above). This usually is fine for most kernels.
However, if the compressed image is actually quite large, then
setup_data will live at a `0x100000 + compressed_size` that extends into
the decompressed zone at 0x1000000. In other words, if compressed_size
is larger than `0x1000000 - 0x100000`, then the decompression step will
clobber setup_data, resulting in crashes.
Visually, what happens now is that QEMU appends setup_data to the kernel
image:
kernel image setup_data
|--------------------------||----------------|
0x100000 0x100000+l1 0x100000+l1+l2
The problem is that this decompresses to 0x1000000 (one more zero). So
if l1 is > (0x1000000-0x100000), then this winds up looking like:
kernel image setup_data
|--------------------------||----------------|
0x100000 0x100000+l1 0x100000+l1+l2
d e c o m p r e s s e d k e r n e l
|-------------------------------------------------------------|
0x1000000 0x1000000+l3
The decompressed kernel seemingly overwriting the compressed kernel
image isn't a problem, because that gets relocated to a higher address
early on in the boot process, at the end of startup_64. setup_data,
however, stays in the same place, since those links are self referential
and nothing fixes them up. So the decompressed kernel clobbers it.
Fix this by appending setup_data to the cmdline blob rather than the
kernel image blob, which remains at a lower address that won't get
clobbered.
This could have been done by overwriting the initrd blob instead, but
that poses big difficulties, such as no longer being able to use memory
mapped files for initrd, hurting performance, and, more importantly, the
initrd address calculation is hard coded in qboot, and it always grows
down rather than up, which means lots of brittle semantics would have to
be changed around, incurring more complexity. In contrast, using cmdline
is simple and doesn't interfere with anything.
The microvm machine has a gross hack where it fiddles with fw_cfg data
after the fact. So this hack is updated to account for this appending,
by reserving some bytes.
Fixup-by: Michael S. Tsirkin <mst@redhat.com>
Cc: x86@kernel.org
Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Message-Id: <20221230220725.618763-1-Jason@zx2c4.com>
Message-ID: <20230128061015-mutt-send-email-mst@kernel.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Eric Biggers <ebiggers@google.com>
Tested-by: Mathias Krause <minipli@grsecurity.net>
Fixup the migration compatibility for existing machine types
so that they do not enable msi-x.
Symptom:
(qemu) qemu: get_pci_config_device: Bad config data: i=0x34 read: 84 device: 98 cmask: ff wmask: 0 w1cmask:0
qemu: Failed to load PCIDevice:config
qemu: Failed to load virtio-rng:virtio
qemu: error while loading state for instance 0x0 of device '0000:00:03.0/virtio-rng'
qemu: load of migration failed: Invalid argument
Note: This fix will break migration from 7.2->7.2-fixed with this patch
bz: https://bugzilla.redhat.com/show_bug.cgi?id=2155749
Fixes: 9ea02e8f1 ("virtio-rng-pci: Allow setting nvectors, so we can use MSI-X")
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20230109105809.163975-1-dgilbert@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: David Daney <david.daney@fungible.com>
Fixes: 9ea02e8f1 ("virtio-rng-pci: Allow setting nvectors, so we can use MSI-X")<br>
Signed-off-by: Dr. David Alan Gilbert <<a href="mailto:dgilbert@redhat.com" target="_blank">dgilbert@redhat.com</a>><br>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
No need to document magic values when the definition names
from "standard-headers/linux/pci_regs.h" are self-explicit.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230105173702.56610-1-philmd@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Bernhard Beschow <shentey@gmail.com>
Presumably TARGET_ARM_64 should be a mistake of TARGET_AARCH64.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20230109063130.81296-1-akihiko.odaki@daynix.com>
Fixes: 27598393a2 ("Lift max memory slots limit imposed by vhost-user")
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The only function ever assigned to AcpiDeviceIfClass::madt_cpu is
pc_madt_cpu_entry() which doesn't use the AcpiDeviceIf parameter.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230121151941.24120-5-shentey@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
hw/acpi/piix4 has its own header with its structure definition etc.
Ammends commit 2bfd0845f0 'hw/acpi/piix4: move PIIX4PMState into
separate piix4.h header'.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230121151941.24120-4-shentey@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Frees isa-bus.c from implicit ACPI dependency.
While at it, resolve open coding of qbus_build_aml() in piix3 and ich9.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230121151941.24120-3-shentey@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Ammends commit 3db119da79 'pc: acpi: switch to AML API composed DSDT'.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230121151941.24120-2-shentey@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Pressing attention button has special meaning when power indicator is
blinking. Better just not do it.
For example, trying to remove device immediately after hotplug leads to
both commands succeded but device not actually unrealized.
Same thing for PCIE hotplug was done in
81124b3c7a "pcie: add power indicator blink check"
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-Id: <20221116214458.82090-1-vsementsov@yandex-team.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
'-drive if=none' is meant for configuring back-end devices only, so this
got marked as deprecated in QEMU 6.2. Users should now only use the new
way with '-drive if=pflash' instead.
Message-Id: <20230112083921.887828-1-thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
virtio_blk_dma_restart_cb() is tricky because the BH must deal with
virtio_blk_data_plane_start()/virtio_blk_data_plane_stop() being called.
There are two issues with the code:
1. virtio_blk_realize() should use qdev_add_vm_change_state_handler()
instead of qemu_add_vm_change_state_handler(). This ensures the
ordering with virtio_init()'s vm change state handler that calls
virtio_blk_data_plane_start()/virtio_blk_data_plane_stop() is
well-defined. Then blk's AioContext is guaranteed to be up-to-date in
virtio_blk_dma_restart_cb() and it's no longer necessary to have a
special case for virtio_blk_data_plane_start().
2. Only blk_drain() waits for virtio_blk_dma_restart_cb()'s
blk_inc_in_flight() to be decremented. The bdrv_drain() family of
functions do not wait for BlockBackend's in_flight counter to reach
zero. virtio_blk_data_plane_stop() relies on blk_set_aio_context()'s
implicit drain, but that's a bdrv_drain() and not a blk_drain().
Note that virtio_blk_reset() already correctly relies on blk_drain().
If virtio_blk_data_plane_stop() switches to blk_drain() then we can
properly wait for pending virtio_blk_dma_restart_bh() calls.
Once these issues are taken care of the code becomes simpler. This
change is in preparation for multiple IOThreads in virtio-blk where we
need to clean up the multi-threading behavior.
I ran the reproducer from commit 49b44549ac ("virtio-blk: On restart,
process queued requests in the proper context") to check that there is
no regression.
Cc: Sergio Lopez <slp@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Message-id: 20221102182337.252202-1-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
ARM_SBCON_I2C() macro and ArmSbconI2CState typedef are
already declared via the QOM DECLARE_INSTANCE_CHECKER()
macro in "hw/i2c/arm_sbcon_i2c.h". Drop the VERSATILE_I2C
declarations from versatile_i2c.c.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20230110082508.24038-5-philmd@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20230110082508.24038-4-philmd@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In order to rename TYPE_VERSATILE_I2C as TYPE_ARM_SBCON_I2C
(the formal ARM naming), start renaming its state.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20230110082508.24038-3-philmd@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20230110082508.24038-2-philmd@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Define TYPE_GPIO_I2C in the public "hw/i2c/bitbang_i2c.h"
header and use it in hw/arm/musicpal.c.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Acked-by: Corey Minyard <cminyard@mvista.com>
Message-id: 20230111085016.44551-2-philmd@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
