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

[Ian Jackson <Ian.Jackson@eu.citrix.com>]

Avi Kivity writes ("Re: [PATCH] hook cpu running at a higher level."):
> I thing it makes sense for you to have multiple vcpus -- that is 
> multiple CPUState objects.  You can still have just one thread (which 
> would be the iothread in kvm's terminology).

Xen does have multiple vcpus (of course) but the vcpus are modelled
entirely in the hypervisor.  No significant amount of state about
these vcpus is in qemu-dm.  Because of the way qemu is constructed we
have to have a CPUState object in qemu-dm but there is only one of it
and it's basically a dummy.  It doesn't contain any of the usual i386
registers.

This will all be a bit weird if you're used to thinking of qemu as a
whole system emulator (which is what it qemu, of course), but of
course Xen didn't need or want the whole system emulator.

>From the point of view of qemu's architecture, it's as if qemu were
emulating a machine consisting of the peripherals plus a (single)
pseudo-CPU which doesn't do anything resembling the execution of
machine instructions (at least as far as qemu is concerned).  This
pseudo-CPU actually consists of much of the rest of the machine,
including the hypervisor and the guest (including all of the guest's
RAM).  Since the state of this pseudo-CPU resides outside qemu, there
is no representation of it inside the qemu-dm process.

The the pseudo-CPU code in qemu-dm is mostly a stub which is
responsible for talking to the parts which actually run the pseudo-CPU
(ie, which actually run the guest's vcpus, maintain the guest's RAM,
and so forth).

> So:
>   tcg - multiplexes all vcpus and io on one thread
>   kvm - iothread + per-vcpu thread
>   xen - iothread, vcpus scheduled by hypervisor

So qemu-dm _is_ the iothread.  The vcpus are elsewhere.

Ian.