-
Notifications
You must be signed in to change notification settings - Fork 118
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
SNP Guest VSM: Start VP hypercall handling #634
Conversation
899e334
to
37d1d1c
Compare
88a2f71
to
b6b0a88
Compare
@@ -420,6 +420,8 @@ pub struct UhCvmVpInner { | |||
tlb_lock_info: VtlArray<TlbLockInfo, 2>, | |||
/// Whether VTL 1 has been enabled on the vp | |||
vtl1_enabled: Mutex<bool>, | |||
/// Whether the VP has been started via the StartVp hypercall. |
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.
Would it make sense for vtl1_enabled to be a ReadWriteLock instead of a Mutex? It seems like we have a lot of paths that read it, but only one that needs to write to it and have exclusive access.
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.
@jstarks I think in the past you've said that RwLocks don't scale to a large number of processors, so I interpreted that as be careful when using them. Do you have general guidelines for when you would choose to use or not use a RwLock? Beyond basing it off the ratio of expected readers to writers?
b6b0a88
to
2547a0e
Compare
2547a0e
to
17a2b57
Compare
Start VP hypercall handling for SNP Guest VSM support.
Tested: