RE: Discussion: Patch series that adds disable-tcg option for ppc targets

[Fabiano Rosas]

Bruno Piazera Larsen <bruno.larsen@eldorado.org.br> writes:

>> You'll probably also need changes in hw/ppc/spapr_hcall.c and maybe
>> some other parts of the spapr code: there are a number of hypercalls
>> that we implement in qemu for TCG, but which are (and must be)
>> implemented in KVM when KVM is in use.  So, I expect you'll need to
>> suppress compilation of h_enter, h_remove, h_protect, h_read and
>> h_bulk_remove at least in the !TCG case.
>
> Yeah. there are 6 files dealing with spapr that are having linking
> problems, though some might be because of the cpu_list problem... But
> I'm a bit confused on how to interface with KVM, do I use an ioctl
> explicitly, or can it handle it implicitly? wenever I google or ask on
> IRC for KVM stuff the answer is usually "KVM handles it" so I never
> know if/when to call it

Maybe a general overview would help:

KVM runs in an actual ppc machine that can execute the Power instruction
set and provide the hardware facilities the guest expects from a ppc
hypervisor. So when using KVM, QEMU only needs to provide things that
are out of the scope of KVM or that for whatever reason KVM cannot
provide.

When running a ppc guest on top of a machine that's from another
architecture or that has KVM disabled, QEMU will need to do all the
heavy-lifting and translate the guest code to the target architecture
(TCG), emulate all of the hardware facilties and so on.

The point with disabling TCG is to make sure we identify which parts of
the code are needed when running natively (KVM) and have a way to build
only those, without the parts that are only needed when running on
another arch (TCG).

So the interfacing with KVM is something that is already in place. If
you grep for ioctl in accel/kvm/kvm-all.c and target/ppc/kvm.c you'll
see how QEMU interacts with KVM to get a guest to run and behave
properly.

About hypercalls (a kind of system call that the guest uses to talk to
its hypervisor) you'll see that spapr_hcall.c contains some hypercall
implementations:

 - The ones used when running TCG (i.e. QEMU pretending we're in an
actual ppc machine), such as h_enter, h_remove, etc;

 - The ones used when running KVM (i.e. KVM says it cannot handle this
hcall and then QEMU has to do it).

If you cross-reference the hcalls from spapr_hcall.c with the
implementations in the kernel at arch/powerpc/kvm/ you'll start to see
which hypercalls are handled by QEMU because we're replacing KVM and
which are handled by QEMU because we're helping KVM.

Note that there are nuances to what I have said, so if you encounter
something that differs we can discuss further.

Hope it helps. =)