ci: AArch64: Enable AArch64 mmio-related integration test cases #1463
Conversation
MrXinWang
force-pushed
the
arm64_integration_cases
branch
from
5f9108c to
6f589e7
Compare
MrXinWang
force-pushed
the
arm64_integration_cases
branch
9 times, most recently
from
833ef2c to
886926d
Compare
|
Some |
MrXinWang
force-pushed
the
arm64_integration_cases
branch
4 times, most recently
from
b1eb2a6 to
55eab89
Compare
|
Extented the sleep time in |
MrXinWang
force-pushed
the
arm64_integration_cases
branch
3 times, most recently
from
1e132b3 to
8f91526
Compare
rbradford
left a comment
rbradford
left a comment
There was a problem hiding this comment.
Oops, sorry I had a pending review here waiting for quite some time!
tests/integration.rs
Outdated
| workload_path.push("workloads"); | ||
|
|
||
| let mut kernel_path = workload_path; | ||
| #[cfg(target_arch = "x86_64")] |
There was a problem hiding this comment.
It would be better to delegate this to a direct_kernel_boot_path()
There was a problem hiding this comment.
Yes definitely. I've updated the code. Hopefully it makes more sense now :)
MrXinWang
force-pushed
the
arm64_integration_cases
branch
3 times, most recently
from
059a476 to
7ed8bf1
Compare
tests/integration.rs
Outdated
| // Creates the path for direct kernel boot and return the path. | ||
| // For x86_64, this function returns the vmlinux kernel path. | ||
| // For AArch64, this function returns the PE kernel path. | ||
| fn direct_kernel_boot_path(workloads_dir: PathBuf) -> Option<PathBuf> { |
There was a problem hiding this comment.
The workloads_dir is always the same so you could make this function take () and instead construct the full path here.
|
|
||
| #[test] | ||
| #[cfg(target_arch = "x86_64")] | ||
| fn test_vhost_user_net_self_spawning() { |
There was a problem hiding this comment.
Why do these tests not work? is vhost-user not supported?
There was a problem hiding this comment.
Emmm some vhost_user test cases failed on both my AArch64 dev machine and the CI machine for following two reasons:
-
Any vhost_user_net case with self-spawning will fail everytime. The VM just cannot be started...
-
the
test_vhost_user_blk_defaultandtest_vhost_user_blk_directcase will randomly fail (1 or 2 fail out of 10). I have literally no idea why this happened. If I run these two cases with exact same configuration and argument on my host manually, it works everytime. However in container the ssh command will randomly fail, leading to the assertion fail. I checked the log and found that the kernel is started....So I am really confused and still debugging this.
As this PR is blocking the PCI related integration test. We will propose another PR after the above bugs are resolved.
There was a problem hiding this comment.
@rbradford Some failed error log can be found here: https://cloud-hypervisor-jenkins.westus.cloudapp.azure.com/blue/organizations/jenkins/cloud-hypervisor/detail/PR-1463/17/pipeline/137
As this failure is really random so I really don't feel comfortable to open these two cases...
There was a problem hiding this comment.
I'm fine with tests being disabled for now. I just wondered if this was a particular vhost-user issue but sounds not.
MrXinWang
force-pushed
the
arm64_integration_cases
branch
2 times, most recently
from
632d33c to
9d71105
Compare
MrXinWang
force-pushed
the
arm64_integration_cases
branch
2 times, most recently
from
35da711 to
0f1ce63
Compare
This commit enables some mmio-related integration test cases on AArch64, including: * some vhost_user test cases * virtio-blk test cases * pmem test cases Also this commit contains a bug fix in creating virtio-blk device. Previously, when creating the FDT, the virtio-blk device was labeled in the reverse order of address allocation. Signed-off-by: Henry Wang <[email protected]>
MrXinWang
force-pushed
the
arm64_integration_cases
branch
from
0f1ce63 to
b6e6d16
Compare
2 participants
This commit enables mmio-related integration test cases on AArch64, including:
Also this commit contains a bug fix in creating virtio-blk device. Previously, when creating the FDT, the virtio-blk device was
labeled in the reverse order of address allocation.
Signed-off-by: Henry Wang [email protected]