Skip to content
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

Merged
merged 1 commit into from
Nov 4, 2022

Conversation

nicholasbishop
Copy link
Contributor

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

@rustbot rustbot added the T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. label Sep 11, 2022
@rust-highfive
Copy link
Collaborator

r? @jyn514

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 11, 2022
@nicholasbishop
Copy link
Contributor Author

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

@jyn514
Copy link
Member

jyn514 commented Sep 11, 2022

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.

@nicholasbishop
Copy link
Contributor Author

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

@jyn514
Copy link
Member

jyn514 commented Sep 11, 2022

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.

@jyn514
Copy link
Member

jyn514 commented Sep 11, 2022

cc @joshtriplett to confirm I have the tier policy correct - only tier 1 has tests, right?

@dvdhrm
Copy link
Contributor

dvdhrm commented Sep 12, 2022

(from https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html)

Tier-2

  • The target must build reliably in CI, for all components that Rust's CI considers mandatory.
  • The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, ./x.py test --no-run, or equivalent "smoke tests". In particular, this requirement may apply if the target builds host tools, or if the tests in question provide substantial value via early detection of critical problems.

@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.

@jyn514
Copy link
Member

jyn514 commented Sep 12, 2022

Ok, in that case I'll marked this as blocked on rust-lang/compiler-team#555.

@jyn514 jyn514 added S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. O-UEFI UEFI and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 12, 2022
Copy link
Contributor

@dvdhrm dvdhrm left a 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.

@the8472
Copy link
Member

the8472 commented Sep 13, 2022

The tests themselves look vaguely right, although I think using QEMU is rather unusual.

We already have some ARM tests running under emulation on x86 CI.

Comment on lines 292 to 294
- name: x86_64-uefi
os: ubuntu-20.04-xl
env: {}
Copy link
Member

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

@nicholasbishop nicholasbishop force-pushed the bishop-add-uefi-ci-2 branch 2 times, most recently from a34dbf0 to be48f46 Compare September 15, 2022 16:39
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'
Copy link
Member

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.

@jyn514
Copy link
Member

jyn514 commented Sep 20, 2022

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
@nicholasbishop
Copy link
Contributor Author

@jyn514 the MCP has been accepted :)

@jyn514
Copy link
Member

jyn514 commented Nov 3, 2022

@bors r+ rollup=iffy

@bors
Copy link
Contributor

bors commented Nov 3, 2022

📌 Commit 1e264ab has been approved by jyn514

It is now in the queue for this repository.

@bors bors removed the S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. label Nov 3, 2022
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Nov 3, 2022
@nicholasbishop
Copy link
Contributor Author

Is bors not working correctly here? https://bors.rust-lang.org/queue/rust doesn't show this PR as approved.

@jyn514
Copy link
Member

jyn514 commented Nov 4, 2022

ugh

@bors r- r+

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 4, 2022
@bors
Copy link
Contributor

bors commented Nov 4, 2022

📌 Commit 1e264ab has been approved by jyn514

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 4, 2022
@bors
Copy link
Contributor

bors commented Nov 4, 2022

⌛ Testing commit 1e264ab with merge c2a5c3a...

@bors
Copy link
Contributor

bors commented Nov 4, 2022

☀️ Test successful - checks-actions
Approved by: jyn514
Pushing c2a5c3a to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 4, 2022
@bors bors merged commit c2a5c3a into rust-lang:master Nov 4, 2022
@rustbot rustbot added this to the 1.67.0 milestone Nov 4, 2022
@nicholasbishop nicholasbishop deleted the bishop-add-uefi-ci-2 branch November 4, 2022 19:45
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (c2a5c3a): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.3% [0.3%, 0.3%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.3% [0.3%, 0.3%] 1

Max RSS (memory usage)

Results

This 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.

mean range count
Regressions ❌
(primary)
0.6% [0.5%, 0.8%] 3
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-1.0% [-1.0%, -1.0%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.2% [-1.0%, 0.8%] 4

Cycles

Results

This 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.

mean range count
Regressions ❌
(primary)
0.5% [0.5%, 0.5%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.6% [-0.6%, -0.6%] 2
Improvements ✅
(secondary)
-4.4% [-4.4%, -4.4%] 1
All ❌✅ (primary) -0.2% [-0.6%, 0.5%] 3

1 similar comment
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (c2a5c3a): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.3% [0.3%, 0.3%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.3% [0.3%, 0.3%] 1

Max RSS (memory usage)

Results

This 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.

mean range count
Regressions ❌
(primary)
0.6% [0.5%, 0.8%] 3
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-1.0% [-1.0%, -1.0%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.2% [-1.0%, 0.8%] 4

Cycles

Results

This 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.

mean range count
Regressions ❌
(primary)
0.5% [0.5%, 0.5%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.6% [-0.6%, -0.6%] 2
Improvements ✅
(secondary)
-4.4% [-4.4%, -4.4%] 1
All ❌✅ (primary) -0.2% [-0.6%, 0.5%] 3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. O-UEFI UEFI S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants