Is CPU timing jitter a usable entropy source? In some virtualized environments, the only source of entropy available is CPU timing jitter.  Can one get enough entropy from this source for practical uses?  Also, is this secure against local side-channel attacks against unprivileged local attackers?

"enough" in this context means "enough to seed a CSPRNG" (256 bits?).
"unprivileged" means that the attacker cannot simply read the RNG state directly because of process or VM isolation.
The problem with CPU jitter is that it is difficult to pin down an accurate physical model of it that would allow you to calculate the entropy involved. Therefore entropy estimates have to largely be grounded on statistical testing, as in the document I linked in the comments.

As you may know, statistical testing alone can only ever give you an upper bound for entropy. What you need for secure random number generation is a lower bound, and that requires making more assumptions.

However, since you only need enough entropy to seed a PRNG, the answer to your question is almost certainly that it does have enough entropy. You can always collect timings for a very long time and feed it all as seed material to the RNG, and unless the jitter contains no entropy at all you will eventually have 256 bits' worth. How long is the question, with no single answer.

If you use a recent Linux kernel, you should be able to get entropy with all that figured out (or guessed...) for you, just by accessing /dev/random or /dev/urandom. In practice it is also often possible to get a small seed into the VM from outside, so you do not necessarily have to rely on the VM being able to generate entropy.