[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c |
Date: |
Fri, 14 Nov 2008 17:20:13 -0600 |
User-agent: |
Thunderbird 2.0.0.17 (X11/20080925) |
Jamie Lokier wrote:
Firstly:
That doesn't make sense: why would you do an expensive TCG translation
every time you hit the same code? After the first encounter, if the
code page hasn't been modified, it should be a TB cache lookup to
already translated code.
Except that once you run under KVM again, you lose all dirty information
and you have to invalidate all TBs.
FWIW, a few years ago, we implemented this concept with QEMU and Xen.
That's where my data is coming from.
I'm guessing the cost of TB cache lookup is much closer to 3k than
300k cycles, maybe even lower...
You're guessing and it doesn't matter anyway because the TB cache has to
be invalidated.
Secondly:
In these cases, you can use a special fast translation (when it's not
cached) which just copies the instructions 1:1 from the guest, simply
converting the special instructions (MMIO, anything else needing it)
to helper calls. That's possible because you know the host is ture
architeccompatible with the guest, as it's running KVM.
You can't copy 1:1 because the instructions aren't 1:1. Only trivial
instructions that manipulate registers remain the same but even then,
you have to do register renaming and on the x86 this probably means
you'll have to spill some registers because you have so few. Any memory
reference (mov, push, pop, etc.) must be translated to a different
instruction because you don't have a virtual address that can be
accessed directly so you need a hook to simulate a tlb miss.
You can preserve atomicity if you try hard enough, but it certainly
isn't a 1:1 translation in softmmu mode.
If you also consider all the potential locking issues with SMP guests, I
think it's pretty likely that there are few cases where dropping to TCG
is going to be a net performance win.
VMware claimed otherwise when Intel first brought out CPU support for
virtualisation.
That's just not true. The paper that you're most likely referencing was
much more nuanced than that and the hardware has improved dramatically
since then.
SMP works fine if you map guest instructions 1:1 to host instructions
with helper calls for special cases. Even atomics, load-locked
sequences and complex weak memory ordering things would behave
correctly.
You can't translate 1:1 so your argument falls apart.
Regards,
Anthony Liguori
Oops, I believe I just argued for keeping the TB cache and code
translation but not using TCG :-)
-- Jamie
- Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c, (continued)
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c, Jamie Lokier, 2008/11/13
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c, Anthony Liguori, 2008/11/14
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c, Anthony Liguori, 2008/11/14