microsoft
openhcl/vmbus_relay: posting sint messages fails when guest enables/disables simp
With certain vmbus clients like the crash vmbus client in windows that enable and disable the simp, it seems that openhcl will attempt to call post_message on the hypervisor with the simp disabled, which the hypervisor will fail.
Unclear if we should queue the message or do something else. See https://openvmm.dev/test-results/test.html?run=18654373886&job=x64-windows-intel-tdx-vmm-tests-logs&test=multiarch__vmbus_relay__hyperv_openhcl_uefi_x64_windows_datacenter_core_2025_x64_prepped_tdx_vmbus_relay_force_mnf# where we are in a bugcheck path, and we attempt to post messages with the simp disabled.
the race here is that we're sending a rescind message for the hvsock connection used by pipette, which we then drop on the floor. Sven is looking to see what the right behavior should be (queue?)
Drop on the floor appears to be the right behavior, or at least that's what Hyper-V host VMBus does in this scenario.
we talked offline - sven will make a change to explicit log this separately and not attempt to post the message to the hypervisor which we know will fail.
dropping messages on the floor seems not great, but I guess we're already in a failure state here?
I think we want to match the behavior of what hyper-v does. We're not in a failure state, but I think the vmbus impl on the crash path is going to ignore these revoke messages anyways.
@smalis-msft Since the guest is responsible both for configuring the synic and initiating contact with the host, I think the host VMBus assumption is "you started talking to me, so you should've already configured the synic so you can receive messages, and if you didn't it's not my problem."
The minivmbus case where the synic is turned on/off repeatedly isn't really covered by that assumption, but in practice it doesn't matter, since as Chris said minivmbus wouldn't know what to do with these messages anyway and would ignore them. Minivmbus's pattern is "enable synic, send message, wait for a response, disable synic." The wait for a response step typically involves looping until a message of the expected type arrives, ignoring everything else.