Re: [Xen-devel] QEMU 2.2.0 in Xen 4.6

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 22 Jan 2015, Eric Shelton wrote:
> On Jan 22, 2015 9:39 AM, "Stefano Stabellini" 
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> >
> > On Thu, 22 Jan 2015, Eric Shelton wrote:
> > > On Fri, 16 Jan 2015, Stefano Stabellini wrote:
> > > > On Thu, 15 Jan 2015, Don Slutz wrote:
> > > > > Now that Xen 4.5 has been released, I would like to see at least QEMU
> > > > > 2.2.0 in qemu-upstream-stable on the master branch.
> > > >
> > > > Agreed
> > >
> > > Is there any concrete plan regarding if and how stub domains will be
> > > implemented for qemu-upstream in 4.6? If not, would you entertain the
> > > idea of someone continuing Anthony's earlier work with a Linux-based
> > > stub domain?
> >
> > I think it would be fantastic if you could pick up Anthony's work on
> > Linux based stubdoms and complete it! I would really like to have
> > upstream QEMU based stubdoms in Xen 4.6!
> >
> > FYI there have been some efforts toward getting upstream QEMU building
> > on rumpkernel (http://wiki.netbsd.org/rumpkernel/), but the work isn't
> > completed, it is difficult to estimate when it is going to be finished
> > and it won't make 4.6. So I think that Linux-based stubdoms would be a
> > great start.
> 
> Stefano,
> 
> Just a brief question, that I did not think needed to go via xen-devel

I think that it is a very reasonable question and might be useful to
others, so I am CC'ing xen-devel back.


> There are several components interacting with each other in the current qemu 
> stubdom:
> - dom0 qemu process
> - stub domain with MiniOS
> - qemu device model running under MiniOS
> - hvm domain with guest OS
> 
> Is there something, or would you mind taking a minute to write up something, 
> that briefly describes this architecture, and how,
> for example, the two qemu instances cooperate and the two domains must 
> cooperate with each other? I can go about figuring this
> out, but a brief primer would speed things up.
 
Sure.

Like you wrote, device emulation is done by QEMU running on top of
MiniOS within the stubdom.

The stubdom itself is a PV guest and as such it connects to PV backends
in Dom0 to get access to disk, network and other PV protocols. But in
the stubdom case, they are the disk and network of the guest. The
stubdom doesn't actually have disk or network for itself. (However it
has a couple of other PV interfaces for special purposes, I'll
talk about them later.)

As usual the PV backends might be running in the Linux kernel or in
userspace in QEMU. Therefore you might have a second QEMU instance
running in Dom0 to provide the PV backends.


HVM guest  ->  QEMU Stubdom (device emulation)  ->  QEMU in Dom0 and Linux (PV 
backends for stubdom)


For example when the HVM guest tries to read from the disk via the
emulated IDE interface, it will trap in Xen and the IO request is going
to be forwarded to QEMU running in the stubdom. QEMU will do the
emulation and eventually will issue a PV read request via MiniOS to the
PV block backend to read from the guest disk. If the PV block backend
is in QEMU, for example because the guest disk is a QCOW2 file, then the
read request will reach the QEMU instance running in Dom0.

In the Linux stubdom case, QEMU running in the stubdom would simply use
the POSIX read syscall to read from the guest disk as usual, then the
Linux kernel in the stubdom would issue the PV block read request to the
backend via xen-blkfront. From QEMU's point of view there should be no
differences between running on a Linux stubdom or in Dom0. Similarly it
is business as usual for the Linux kernel: it is running just as a
regular PV guest.

In addition the stubdom is provided with 3 "special" PV console
interfaces, the first one is used for logging the stubdom's own output,
the second one is used to save the state of emulated devices and the
third one if used to read the state of emulated devices. The last two
are only used for save/restore purposes. See
tools/libxl/libxl_dm.c:spawn_stub_launch_dm.

To complicate matter further, the HVM guest could be running PV
frontends of its own.  For example the Windows PV Drivers. They would be
connecting to a separate set of PV backends in Dom0.  Again if one or
more PV backends are running in QEMU, there is going to a third QEMU
instance to provide PV backends to the guest.


HVM guest ---------(PV)----------> QEMU in Dom0 for guest
    |
    --(emulation)--> QEMU Stubdom-(syscall)->Linux Stubdom---(PV)--> QEMU Dom0 
for stubdom


I hope I managed to make things clearer for you.

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel