feat(itf): add dual-QEMU ivshmem integration-test environment - #617
Conversation
f56837b to
eedfda4
Compare
5bd6beb to
38c934b
Compare
castler
left a comment
There was a problem hiding this comment.
Let's first align on the test infrastructure - then we can check out the example :)
| # Driving two real QNX guests under KVM has rare, environment-induced boot | ||
| # nondeterminism (e.g. a guest occasionally wedging during device bring-up). | ||
| # The fixtures already stagger boots and wait for stable SSH; mark the test | ||
| # flaky so bazel transparently retries such infrastructure hiccups. |
There was a problem hiding this comment.
Ouch - is this possible to be fixed? Should we add a ticket with a todo?
There was a problem hiding this comment.
It's a KVM + QNX -kernel boot path timing issue — the second guest occasionally wedges during SMP AP startup when both initialize under the same KVM instance. The plugin already mitigates by booting VMs sequentially and using single-core guests, which makes it very rare but not fully eliminable from our side.
A proper fix would require either:
- QNX fixing the boot-path race in their -kernel loader (upstream QNX issue), or
- Using the -bios/UEFI boot path instead of -kernel (different QNX IFS packaging, not trivial).
6c98422 to
01bea3d
Compare
b783e72 to
535aa46
Compare
535aa46 to
1b86c08
Compare
|
@Rahul-Sutariya some checks are failing in your PR. Please adapt. |
@anmittag as already stated in #617 (comment), this is right now blocked. |
Add a `dual_qemu` ITF/pytest plugin that boots two QNX VMs sharing one QEMU ivshmem-plain region, extending the upstream single-VM `qemu` plugin. - plugin: config.py, ivshmem_qemu.py, dual_qemu_process.py, __init__.py (target_a/target_b fixtures; sequential boot to avoid KVM race), BUILD, example config, README, example/run_example_manually.sh. - integration_testing.bzl: dual_qemu_integration_test macro (QNX-only, flaky). - example: offset_list.h + simple_ivshmem.cpp map the ivshmem BAR via pci-server and exchange a self-relative offset-pointer list, proving cross-VM pointer resolution; simple_ivshmem_test.py verifies both VMs.
note: Cross-VM shared memory forces the region onto the ivshmem PCI BAR (device/SHMCTL_PHYS memory), but the production lib-memory ControlBlock puts a process-shared pthread_mutex there and locks it during init. QNX refuses to operate a process-shared mutex on device-mapped BAR memory (returns EINVAL even with write-back caching), so the producer aborts — making the umbrella score::memory::shared unusable over ivshmem, unlike the mutex-free demo.
1b86c08 to
ac16d8b
Compare
Add a
dual_qemuITF/pytest plugin that boots two QNX VMs sharing one QEMU ivshmem-plain region, extending the upstream single-VMqemuplugin.