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

[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.

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.

Regards,

Anthony Liguori

> Cheers
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>