-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add QEMU test for x86_64-unknown-uefi #101703
Conversation
r? @jyn514 (rust-highfive has picked a reviewer for you, use r? to override) |
I don't have any prior knowledge of the Rust CI, and I didn't see any existing CI jobs that looked like a good analog for what I was trying to do here. So, I'm not sure if this is the right way to go about it -- any feedback appreciated :) CC @dvdhrm |
782cafa
to
b9289ce
Compare
The tests themselves look vaguely right, although I think using QEMU is rather unusual. What tier is UEFI? I was under the impression it's tier 3, which we don't test. |
You are correct that UEFI is currently tier 3, however there is an open proposal to move to tier 2: rust-lang/compiler-team#555 |
Ok. The way the tier system works is that tier 3 has support but no CI, tier 2 is built in CI but not tested, and only tier 1 is tested. So I can't accept this PR unless UEFI is tier 1 (which seems unlikely). Once your MCP is accepted, you can change it to build only and we can merge that. |
cc @joshtriplett to confirm I have the tier policy correct - only tier 1 has tests, right? |
(from https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html)
@jyn514, my interpretation is that basic target tests are allowed for Tier-2 targets, explicitly mentioning a hello-world program as suggested here. It is, however, unclear to me whether this requires approval by a team. The wording only defines the inverse, in that if it is asked for, it must be provided. Maybe Josh can shed some light on this. |
Ok, in that case I'll marked this as blocked on rust-lang/compiler-team#555. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for submitting this! Looks all good to me, a few minor questions inline.
src/ci/docker/host-x86_64/x86_64-uefi/uefi_qemu_test/src/main.rs
Outdated
Show resolved
Hide resolved
src/ci/docker/host-x86_64/x86_64-uefi/uefi_qemu_test/src/main.rs
Outdated
Show resolved
Hide resolved
We already have some ARM tests running under emulation on x86 CI. |
.github/workflows/ci.yml
Outdated
- name: x86_64-uefi | ||
os: ubuntu-20.04-xl | ||
env: {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might fit into the test-various
job? That currently 37minutes so it's one of the shorter-running jobs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nicholasbishop can you please make this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
One thing to note is that the test-various
Dockerfile is using Ubuntu 20.04, which provides a quite old QEMU (4.2.1). That version of QEMU likes to crash on exit with OMVF, we ran into that problem in the CI for uefi-rs in the past. I changed the test to not check the exit status of the VM, which I think is fine since we're checking the stdout for a specific string anyway.
a34dbf0
to
be48f46
Compare
def build_and_run(tmp_dir): | ||
host_artifacts = Path('/checkout/obj/build/x86_64-unknown-linux-gnu') | ||
stage0 = host_artifacts / 'stage0/bin' | ||
stage2 = host_artifacts / 'stage2/bin' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hard coding the target and directory structure here makes me a little nervous ... I guess if it breaks it will break quickly in CI. It would still make me more comfortable to make this managed by bootstrap, but I won't block on that.
r=me with #101703 (comment) done and the MCP accepted :) |
The UEFI targets don't have std support yet, so the normal tests don't work. However, we can compile a simple no-std program and run it under QEMU to at least check that the target compiles, links, and runs. Tested locally with: src/ci/docker/run.sh test-various
be48f46
to
1e264ab
Compare
@bors r+ rollup=iffy |
Is bors not working correctly here? https://bors.rust-lang.org/queue/rust doesn't show this PR as approved. |
ugh @bors r- r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (c2a5c3a): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
1 similar comment
Finished benchmarking commit (c2a5c3a): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
The UEFI targets don't have std support yet, so the normal tests don't work. However, we can compile a simple no-std program and run it under QEMU to at least check that the target compiles, links, and runs.
Tested locally with:
src/ci/docker/run.sh x86_64-uefi