-
Notifications
You must be signed in to change notification settings - Fork 40
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
cpu/tlb: do not broadcast per-cpu TLB flushes #417
Conversation
f963244
to
168fe7a
Compare
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.
Left a few minor suggestions, other than that this looks good to me. I'll merge once comments are marked as resolved.
All platforms capable of virtualization support PGE and NX, so there is no reason to make these features optional in the SVSM code base. Signed-off-by: Jon Lange <[email protected]>
VM ranges that are specific to a single CPU do not require TLB invalidations to be broadcast to multiple processors. This is especially important during the early boot phase when no other processors are online and when the infrastructure required to broadcast TLB invalidations may not yet be fully initialized. The same is true for temporary mappings established in a per-CPU address range. Signed-off-by: Jon Lange <[email protected]>
In-SVSM tests fail after the last commit in this PR (e1c168b):
|
Happens only on debug builds it seems. It also can happen even earlier, so the test that failed above is not to blame:
|
Aaaand it went away with the latest nightly toolchain version, so not sure why it was failing. It also only failed when applying the I'll try again tomorrow and see if everything works properly. |
VM ranges that are specific to a single CPU do not require TLB invalidations to be broadcast to multiple processors. This is especially important during the early boot phase when no other processors are online and when the infrastructure required to broadcast TLB invalidations may not yet be fully initialized. The same is true for temporary mappings established in a per-CPU address range.