Timing. Perhaps a malicious microcode could introduce key-dependent delays into AES encryption/decryption? That's a pretty long shot, though; given my understanding of modern CPUs it's unlikely to be possible.
Another hypothetical attack: the AES instructions could be modified to store plain text and/or keys in cache, with a specific set of innocuous opcodes and register values triggering a readout of the data. This would allow one VM on a physical server to steal keys or data from another VM on the same server.
It seems unlikely, though, due to the probability that an adversary that controls both CPU microcode and VM placement probably has access to the hypervisor.
