[Qemu-devel] Re: [PATCH] hook cpu running at a higher level.

[Ian Jackson]

Glauber Costa writes ("[PATCH] hook cpu running at a higher level."):
> This patch removes the kvm_enabled() check from cpu-exec.c.
> This file is highly tcg-specific, and we'll probably want it
> out when tcg is not compiled in (coming soon, in a theathe near you)

That would be interesting, certainly.  We don't compile that file
anyway right now, and have our own version of exec.c too (sadly it's
somewhat clone-and-hack and it would be nice to make that neater in
due course).

> Instead, we hook at the main loop level. The amount of code
> duplication introduced is at worst, acceptable, and I believe
> it pays. The tcg mainloop is likely to be different from the
> hypervisors ones, since tcg runs all cpus in lockstep. KVM
> (and probably xen), will be able to span threads out for its
> vcpus.

I don't have an opinion about this patch really, but I did want to
comment slightly on the way Xen does things just for future reference.

The Xen qemu process runs only in one thread which is fine because it
doesn't need to be involved with actual processor execution.  In
theory parallel execution (in different threads and thus on different
physical cpus) of IO emulations requested by different guest vcpus
might make some small performance difference but I doubt it would be
worth our while.  So I think the Xen setup will still from qemu's
point of view look like a single vcpu no matter how many vcpus the
guest aactually has.

> -    main_loop();
> +    if (kvm_enabled())
> +        kvm_main_loop();
> +    else
> +        main_loop();
> +

The way we have approached these problems in the Xen tree is to supply
an alternative implementation of (say) main_loop and arrange for the
standard one not to be compiled.  Is it the intent to make kvm a
run-time selectable option ?  It seems to me that that given that we
already have different qemu builds for all of the various target
(guest) cpu architectures, it might be simpler to continue that
approach.  With a bit of judicious movement of code into appropriate
files, this will avoid the need for ifs and ifdefs.

Regards,
Ian.