Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-25-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>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-18-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
hotplugged bridges should not be described in DSDT,
while it works on cold boot, some ACPPI PCI code
are invoked during reboot.
This patch will let us catch unexpected AML if hotplug
checks are broken.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-17-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
if the function is called the 2nd time within the same qtest session,
it will prematurely return before boot sector is executed due to
remaining signature.
Follow up patch will add VM reboot to a test case and will
call boot_sector_test() again within the same qtest env,
which may lead to above issue.
To fix it make sure signature in VM RAM is no more before
exiting boot_sector_test(), so next time it's called it
will wait boot sector is completed again.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-16-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
with previous commit fixing malformed PCNT calls to hotplugged
bridges, it should be possible add coldplug/hotplug test when
describing PCI topology in DSDT without breeaking CI.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-15-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
If test case was started in paused mode (-S CLI option) and then
allowed to continue via QMP, boot_sector_test could assert on
transient state with following error:
assertion failed (qdict_get_try_str(qret, "status") == "running"): (NULL == "running")
Instead of crashing test if 'status' is not available yet, skip check
and repeat iteration again after TEST_DELAY has elapsed.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-14-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>
'use_uefi' is used for the flag is a part of 'test_data *data'
argument that is passed to the same functions, which
makes use_uefi argument redundant.
Drop it and use 'data::uefi_*' directly, instead.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-7-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
add extra nested bridges/root ports to blobs so it would be
posible to check how follow up patches would affect it.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-6-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
add nested bridges/root-ports to pcihp tests, to make sure
follow up patches don't break nested enumeration of bridges
in DSDT.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-5-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-4-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
no functional change
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230112140312.3096331-3-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-2-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>
It seems not super clear on when iova_tree is used, and why. Add a rich
comment above iova_tree to track why we needed the iova_tree, and when we
need it.
Also comment for the map/unmap messages, on how they're used and
implications (e.g. unmap can be larger than the mapped ranges).
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20230109193727.1360190-1-peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
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>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230120082341.59913-2-philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
This test is failing in gtk-vnc on Darwin:
$ make check-qtest-aarch64
...
19/20 qemu:qtest+qtest-aarch64 / qtest-aarch64/vnc-display-test
ERROR **: 10:42:35.488: vnc-error: Unsupported auth type 17973672
While QEMU picks the sigaltstack coroutine backend, gtk-vnc uses
the ucontext coroutine backend, which might be broken on Darwin.
Disable this test (current problem being investigated in this thread:
https://lore.kernel.org/qemu-devel/Y8kw6X6keB5l53nl@redhat.com/).
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230119120514.28778-4-philmd@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
If we don't specify any machine, an architecture default
might be picked. But some architectures don't provide any
default, such ARM:
$ make check-qtest-aarch64
...
19/20 qemu:qtest+qtest-aarch64 / qtest-aarch64/vnc-display-test
qemu-system-aarch64: No machine specified, and there is no default
Since we don't need any particular machine to run this VNC
test, use the 'none' machine.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230119120514.28778-3-philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
While this test is skipped on Windows, we still get when building:
tests/qtest/vnc-display-test.c:22:20: warning: unused function 'on_vnc_error' [-Wunused-function]
static inline void on_vnc_error(VncConnection* self,
^
tests/qtest/vnc-display-test.c:28:20: warning: unused function 'on_vnc_auth_failure' [-Wunused-function]
static inline void on_vnc_auth_failure(VncConnection *self,
^
2 warnings generated.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230119120514.28778-2-philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The tests under tests/tcg depend on the TCG accelerator. Do not build
them if --disable-tcg was given in the configure line.
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230120184825.31626-7-farosas@suse.de>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The HAXM project has been retired (see https://github.com/intel/haxm#status),
so we should mark the code in QEMU as deprecated (and finally remove it
unless somebody else picks the project up again - which is quite unlikely
since there are now whpx and hvf on these operating systems, too).
Message-Id: <20230126121034.1035138-1-thuth@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Abort the maintenance of Guest CPU Cores (HAXM).
* Clean up the maintainer list of X86 HAXM CPUs
* Remove the web page URL and the mailing list
* Change the status to Orphan
Reviewed-by: Hang Yuan <hang.yuan@intel.com>
Signed-off-by: Wenchao Wang <wenchao.wang@intel.com>
Message-Id: <DM6PR11MB40903B55C23D5140E5BEF17687C49@DM6PR11MB4090.namprd11.prod.outlook.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Since commit efc6c070ac ("configure: Add a test for the minimum
compiler version") the minimum compiler version required for GCC
is 4.8, which supports __builtin_bswap().
Remove the NetBSD specific ifdef'ry.
This reverts commit 1360677cfe
("makes NetBSD use the native bswap functions").
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230111163147.71761-7-philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Since commit efc6c070ac ("configure: Add a test for the minimum
compiler version") the minimum compiler version required for GCC
is 4.8, which supports __builtin_bswap().
Remove the FreeBSD specific ifdef'ry.
This reverts commit de03c3164a
("bswap: Fix build on FreeBSD 10.0").
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230111163147.71761-6-philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Since commit efc6c070ac ("configure: Add a test for the minimum
compiler version") the minimum compiler version required for GCC
is 4.8, which supports __builtin_bswap().
Remove the Haiku specific ifdef'ry.
This reverts commit 652a46ebba
("bswap.h: Include <endian.h> on Haiku for bswap operations").
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230111163147.71761-5-philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Since commit efc6c070ac ("configure: Add a test for the minimum
compiler version") the minimum compiler version required for GCC
is 4.8, which supports __builtin_bswap().
Drop the <byteswap.h> dependency.
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230111163147.71761-4-philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230111163147.71761-3-philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Use the compiler built-in function to byte swap values,
as the compiler is clever and will fold constants.
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230111163147.71761-2-philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
No need to recompile the dtc submodule here again and again, we can
use the pre-built binary from the distribution instead.
(And this will also help in case we finally get rid of the dtc submodule
in QEMU one day)
Message-Id: <20230124143824.844040-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Each job uses its own addons section nowadays, so the generic section
is completely unused and outdated, thus we can remove it now.
Message-Id: <20230119135914.2040853-1-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
No need to compile-test third party submodules over and over again if
we can simply use the pre-build library from the distribution instead.
By also adding --enable-fdt=system to the configure options, we can
also avoid to check out the "dtc" submodule here.
Message-Id: <20230120075330.2076773-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
