-
Notifications
You must be signed in to change notification settings - Fork 123
Wait for VF ownership before GdmaDriver destroy HWC #1436
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
base: main
Are you sure you want to change the base?
Conversation
@yuqiong6 please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
.read_u32(self.bar0.map.vf_gdma_sriov_shared_reg_start as usize + 28); | ||
if data == u32::MAX { | ||
tracing::error!("Device no longer present"); | ||
const LOG_CTX: &str = "After GdmaDriver destroy HWC"; |
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.
It feels like this one and the other one are for debugging?
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.
Yes, you’ve got it. LOG_CTX is just a temporary context string we pass to the tracing macros for debugging.
let data = self.bar0.mem.read_u32(offset); | ||
|
||
if data == u32::MAX { | ||
tracing::error!("Device no longer present: {}", log_ctx); |
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.
trace actual values, not string interpolated, as the point of tracing should be to trace the actual values and let the subscriber decide how to handle it.
in this case, it would look something like:
tracing::error!(log_ctx, "device no longer present")
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 noticed that the original code at line 214 also uses string interpolation:
tracing::error!("DESTROY_HWC failed: {}", header.status());
To maintain consistency with the existing style, I used string interpolation in this case as well.
I would recommend keeping it as is for consistency.
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.
No, that's not how tracing should be used. That line should be fixed too, as should anywhere else we're using string interpolation.
/// Polls the shared‐memory ownership bit until PF gives it back (or we timeout / device not present). | ||
/// Returns `Some(header)` if we successfully see VF ownership (i.e. PF bit cleared), | ||
/// or `None` if the device not present or we hit our timeout. | ||
fn wait_for_vf_to_own_shmem(&self, log_ctx: &str) -> Option<SmcProtoHdr> { |
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.
instead of passing log context, you can return a Result<SmcProtoHdr>
and then on the caller end you can do self.wait_for_vf_to_own_shmem().context(log context here)?;
} | ||
|
||
let header = SmcProtoHdr::from(data); | ||
if !header.owner_is_pf() { |
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.
Maybe we should also check for header.reset_vf() { and return error }
@jimdaubert-ms - What do you think?
if data == u32::MAX { | ||
tracing::error!("Device no longer present"); | ||
|
||
// Wait for the device to respond. |
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 are not waiting for the device to respond here as we haven't posted any message on the SHMEM yet. Here, we are waiting for the SHMEM ownership with the VF before posting on the SHMEM. So, a better comment would be something like "Wait for VF ownership of the shared memory"
Underhill currently doesn’t verify VF ownership before issuing a shared-memory request to destroy the HWC. It blindly sends the request and then waits for a response. If the VF doesn’t actually own that shared memory, the request may never go out, and we can’t tell whether it failed to send or the response was simply lost.
To fix this, each shmem command should first confirm VF ownership of the target memory before dispatching the request. That way, a later timeout unambiguously indicates that the request was sent but no response arrived.
We verified the code by running unit tests locally and performing the FHR in the TiP session, both succeeded.