For reads across different VMs on the same CPU, theoretically TME-MK could mitigate the usefulness of the memory reads by having each VM access memory using a different memory encryption key, but I don't know of any hypervisors that implement this.
AMD has had SEV support in QEMU for a long time, which some cloud hosting providers use already, that would mitigate any such issue if it occurred on AMD EPYC processors.
Memory encryption doesn't usually protect against these kinds of side channels. You're not reading memory directly, but inferring it based on discernible behavior of the privileged code. Inasmuch as SEV and TME-MK are marketed as protecting VM guest memory from host machine snooping, they've proven insufficient many times before.[1] In the end, you have to trust your VM hosting provider, and trust that they've written their hypervisors in a robust way that takes into account these unforeseen (yet predictable) issues when isolating guests from each other.
Memory encryption typically doesn't keep anything encrypted within the CPU (e.g. in caches). Haven't looked at the details of this bug but I expect it wouldn't help for that reason.
AMD has had SEV support in QEMU for a long time, which some cloud hosting providers use already, that would mitigate any such issue if it occurred on AMD EPYC processors.