virt_mshv_vtl/mshv: Cleanup TLB lock tracking

[smalis-msft]

Don't bother telling the hypervisor what it already knows. Also fixup ARM code, since it wasn't handling this.

[jstarks]

I don't understand this change. AFAICT, the only non-assertion place where we call this is when we are taking the TLB lock. We sure don't want to add an extra hypercall into that path--we might as well just take the lock.

What's the motivation behind this change?

[jstarks]

x

[smalis-msft]

The motivation behind this is that there were cases found where said debug_asserts were failing. This fixes them. The logic beforehand was incomplete.

[jstarks]

The motivation behind this is that there were cases found where said debug_asserts were failing. This fixes them. The logic beforehand was incomplete.

If there are cases where we know the TLB is locked (we are asserting on it, after all), and we expect the hypervisor to say the TLB is locked, doesn't that imply we just failed to record our knowledge somewhere? I.e., shouldn't we have manually set the local cache in some place?

[smalis-msft]

The case that I found was when we are provided an initial_gva_translation from the hypervisor. We use that instead of translating the gpa ourselves, which means we never interact with our own tlb lock machinery. We don't really have a great place to set our local lock in that flow. Also there's nothing stopping the hypervisor from locking the TLB on other paths, and this code should be correct in the general case for any future callers.