From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: QEMU 2.2.0 in Xen 4.6 Date: Fri, 23 Jan 2015 14:42:44 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1342847746-1776754432-1422017657=:18131" Return-path: In-Reply-To: Content-ID: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Eric Shelton Cc: xen-devel@lists.xensource.com, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org --1342847746-1776754432-1422017657=:18131 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Thu, 22 Jan 2015, Eric Shelton wrote: > On Jan 22, 2015 9:39 AM, "Stefano Stabellini" 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?=C2=A0 If not, would you enterta= in 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!=C2=A0 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.=C2=A0 So I think that Linux-based stubdoms would= be a > > great start. >=20 > Stefano, >=20 > 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 q= emu stubdom: > - dom0 qemu process > - stub domain with MiniOS > - qemu device model running under MiniOS > - hvm domain with guest OS >=20 > Is there something, or would you mind taking a minute to write up somethi= ng, that briefly describes this architecture, and how, > for example, the two qemu instances cooperate and the two domains must co= operate with each other?=C2=A0 I can go about figuring this > out, but a brief primer would speed things up. =20 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 D= om0 for stubdom I hope I managed to make things clearer for you. Cheers, Stefano --1342847746-1776754432-1422017657=:18131 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --1342847746-1776754432-1422017657=:18131--