Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c

["andrzej zaborowski" <balrogg@gmail.com>]

2008/11/13 Anthony Liguori <anthony@codemonkey.ws>:
> andrzej zaborowski wrote:
>> Is this going a bit in the opposite direction to where QEMUAccel is
>> going?  What Fabrice suggests seems to be like QEMUAccel, with TCG
>> treated as another accelerator.
>>
>
> QEMUAccel is a bit orthogonal to what I'm talking about.  There is already
> KVM support in QEMU today and I'm merely looking to restructure existing
> code so that I can build a version of QEMU that has no TCG support, only KVM
> support.  TCG is too intimately woven into QEMU right now.  You could think
> of this perhaps as a precursor to making TCG more of an "accelerator" than
> it is today.

Ah, I agree with your patch, I was only commenting on the idea of
*-kvm/ targets.  I see something like QEMUAccel as a way to turn on
and off the cpu emulators (TCG, kvm, kqemu).  Ofcourse, kqemu depends
on a fallback emulator - currently TCG - I guess it could be possible
to run kqemu with kvm as the fall back and not compile in TCG (even if
not a very useful configuration).

>
> But wrt QEMUAccel and KVM, there are 5 places in QEMU where there is KVM
> specific code.
>
> One is cpu-exec.c to invoke the kvm exec routine instead of TCG.  kqemu has
> something similar.  Unfortunately, kqemu relies on some state that's only
> available in cpu-exec.c so we can't make this a single function pointer
> invocation without major surgery on cpu-exec.
>
> One is vl.c to initialize KVM support.  kqemu doesn't need this.
>
> One is exec.c, to hook cpu_register_physical_memory.  kqemu does this too so
> it could conceivably be a hook.
>
> Another one is monitor.c to implement 'info kvm'.  Not really a place for a
> hook.  Ideally we could register the monitor callback from kvm-all.c when we
> initialize KVM.
>
> Finally, there is a hook in hw/acpi.c to disable SMM support when using KVM.
>  This is KVM specific because KVM doesn't support SMM.  kqemu uses TCG to
> run SMM code.
>
> Since there is only one shared hook ATM, I don't think something like
> QEMUAccel is all that useful for KVM.  On the other hand, there are 42
> places that are kqemu specific.  I think kqemu could be refactored to
> eliminate most of these.
>
> kqemu relies on TCG so you can't really decouple them from each other.
>
>> BTW It would be great if before merging a change like this you
>> review/merge the patches submitted to the list that might touch the
>> same area so as not to break them (such as Jan Kiszka's
>> single-stepping/watchpoint fixes).
>>
>
> Yeah, I will make sure to.

Many thanks for that.

Regards