-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Guest vs host features check #4884
base: main
Are you sure you want to change the base?
Guest vs host features check #4884
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4884 +/- ##
=======================================
Coverage 84.10% 84.10%
=======================================
Files 251 251
Lines 28080 28080
=======================================
Hits 23616 23616
Misses 4464 4464
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
64c7e72
to
e81248e
Compare
e81248e
to
41b2748
Compare
tests/integration_tests/functional/test_cpu_features_aarch64.py
Outdated
Show resolved
Hide resolved
@pytest.mark.skipif( | ||
PLATFORM != "aarch64", | ||
reason="This is aarch64 specific test.", | ||
) |
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.
We could make this test more generic and support x86_64. Maybe it belongs in a generic test_cpu_features.py
(and move the current test_cpu_features.py
to test_cpu_features_x86.py
)
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.
I would prefer to keep our current separation where test_cpu_feautres
is for x86 and test_cpu_features_aarch64
is for aarch64. No reason for creating some new file for a singe test.
I don't mind renaming test_cpu_features
to test_cpu_features_x86
though.
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.
On the other hand, we should look for any opportunities to consolidate and unify those tests. I think this test could be the first step in that direction.
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.
These are 2 different architectures, we don't need to unify tests for them.
@@ -10,6 +10,8 @@ | |||
from framework.utils import check_output | |||
from framework.utils_imdsv2 import imdsv2_get | |||
|
|||
CPU_FEATURES_CMD = r"lscpu |grep -oP '^Flags:\s+\K.+'" |
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.
Since right now it is used in a single test, I think it should stay closer to where it's used.
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.
Idea is that it might be used in x86 version of this test. I did not implement it here though.
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.
In that case we can wait until that happens, but in general this test is simple enough that could work for both architectures.
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.
I added x86_64 test as well, so this global constant is now used in 2 places.
} | ||
assert guest_feats - host_feats == {"ssbs"} | ||
case _: | ||
assert False, f"Cpu model {cpu_model} is not supported" |
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.
Let's not have tests that fail unconditionally locally. Can we have this be behind a sort of if env.get("buildkite") is not None:
?
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.
what is the problem with this test failing on an instance for which we don't have cpu feature diff?
41b2748
to
e813c62
Compare
match cpu_model: | ||
case CpuModel.ARM_NEOVERSE_N1: | ||
assert host_feats - guest_feats == set() | ||
assert guest_feats - host_feats == {"ssbs"} |
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.
Ideally we should have explanations for why we have those differences (possibly with pointers to our docs).
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.
added notes to the aarch64 test. Not sure how to describe the diffs for x86_64 test though.
9593771
to
6ce3d2b
Compare
Add test comparing host and guest default cpu features. Signed-off-by: Egor Lazarchuk <[email protected]>
efdf8ee
to
f56f348
Compare
Add test comparing host and guest default cpu features. Signed-off-by: Egor Lazarchuk <[email protected]>
f56f348
to
9cb0669
Compare
Changes
Add tests comparing host and guest default cpu features.
Reason
We want to know what is the difference between cpu features on the host and in the guest.
License Acceptance
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md
.PR Checklist
PR.
CHANGELOG.md
.TODO
s link to an issue.contribution quality standards.
rust-vmm
.