From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60422 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OjyAx-0003Lg-8Q for qemu-devel@nongnu.org; Fri, 13 Aug 2010 13:36:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OjyAm-0005lT-76 for qemu-devel@nongnu.org; Fri, 13 Aug 2010 13:36:05 -0400 Received: from mail-qy0-f173.google.com ([209.85.216.173]:61253) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OjyAm-0005lM-3m for qemu-devel@nongnu.org; Fri, 13 Aug 2010 13:36:04 -0400 Received: by qyk5 with SMTP id 5so486765qyk.4 for ; Fri, 13 Aug 2010 10:36:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <19557.16086.677317.207260@mariner.uk.xensource.com> References: <1281622202-3453-3-git-send-email-stefano.stabellini@eu.citrix.com> <19557.16086.677317.207260@mariner.uk.xensource.com> From: Blue Swirl Date: Fri, 13 Aug 2010 17:35:42 +0000 Message-ID: Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 03/15] xen: Add a new target to qemu: target-xen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Jackson Cc: Anthony.Perard@citrix.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org, stefano.stabellini@eu.citrix.com On Fri, Aug 13, 2010 at 12:47 PM, Ian Jackson w= rote: > Blue Swirl writes ("[Xen-devel] Re: [Qemu-devel] [PATCH 03/15] xen: Add a= new target to qemu: target-xen"): >> I don't understand why it would be a target, QEMU calls CPU >> architectures targets. Isn't it possible to have Xen for Sparc, PPC or >> ARM? It should really be just a machine, not copy&paste from x86 >> target. > > Qemu's targets include much more of Qemu's system emulation than is > appropriate for Xen, because the hypervisor is doing more of the > work. =C2=A0For example, there is no representation of the guest CPU stat= e > outside the hypervisor so Qemu doesn't see that at all. But you could easily ignore QEMU's CPU state, or even better would be to support some kind of CPU state synchronization. KVM also manages the CPU when it is charge, but at the transition points the state is synched with QEMU state. For example, what should happen to CPU on system reset on Xen? In this version, reset is completely ignored. About the other changes, for example cpu_physical_memory_map() seems to do very different things on Xen than QEMU. But this can be handled easily by adding some kind of indirection to exec.c or just: if (xen_enabled()) { xen_func(); } else { tcg_func(); } or add stubs for non-Xen case and then: xen_func(); if (!xen_enabled()) { tcg_func(); } > So it makes sense to do Xen emulation in Qemu as a new target than > just as a machine. It's also possible to add a new x86 CPU model like 'xen-x86'. > Yes, in principle Xen for Sparc, PPC and ARM are possible; some of > these have existed in the past although targets other than i386, > itanium and amd64 aren't currently supported by xen-unstable. =C2=A0So > perhaps the currently-introduced xen target should be called > target-i386-xen. =C2=A0However, in practice since in a Xen system Qemu > doesn't deal with CPU instructions these other targets will be much > more like each other than (say) i386 is close to m68k. > > Or to put it all another way: from the point of view of Qemu, Xen is > a weird kind of cpu architecture whose instruction emulation is done > "by magic" and Qemu doesn't need to care vary much about that. I don't see how this is so different from KVM, which is integrated to QEMU cleanly. Even if the changes would be more invasive that way (like the memory changes which KVM hasn't done so far), I'd still think that would be better for everyone than having two versions of the same code with some changes. They would eventually drift apart. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Blue Swirl Subject: Re: Re: [Qemu-devel] [PATCH 03/15] xen: Add a new target to qemu: target-xen Date: Fri, 13 Aug 2010 17:35:42 +0000 Message-ID: References: <1281622202-3453-3-git-send-email-stefano.stabellini@eu.citrix.com> <19557.16086.677317.207260@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <19557.16086.677317.207260@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: Anthony.Perard@citrix.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On Fri, Aug 13, 2010 at 12:47 PM, Ian Jackson w= rote: > Blue Swirl writes ("[Xen-devel] Re: [Qemu-devel] [PATCH 03/15] xen: Add a= new target to qemu: target-xen"): >> I don't understand why it would be a target, QEMU calls CPU >> architectures targets. Isn't it possible to have Xen for Sparc, PPC or >> ARM? It should really be just a machine, not copy&paste from x86 >> target. > > Qemu's targets include much more of Qemu's system emulation than is > appropriate for Xen, because the hypervisor is doing more of the > work. =C2=A0For example, there is no representation of the guest CPU stat= e > outside the hypervisor so Qemu doesn't see that at all. But you could easily ignore QEMU's CPU state, or even better would be to support some kind of CPU state synchronization. KVM also manages the CPU when it is charge, but at the transition points the state is synched with QEMU state. For example, what should happen to CPU on system reset on Xen? In this version, reset is completely ignored. About the other changes, for example cpu_physical_memory_map() seems to do very different things on Xen than QEMU. But this can be handled easily by adding some kind of indirection to exec.c or just: if (xen_enabled()) { xen_func(); } else { tcg_func(); } or add stubs for non-Xen case and then: xen_func(); if (!xen_enabled()) { tcg_func(); } > So it makes sense to do Xen emulation in Qemu as a new target than > just as a machine. It's also possible to add a new x86 CPU model like 'xen-x86'. > Yes, in principle Xen for Sparc, PPC and ARM are possible; some of > these have existed in the past although targets other than i386, > itanium and amd64 aren't currently supported by xen-unstable. =C2=A0So > perhaps the currently-introduced xen target should be called > target-i386-xen. =C2=A0However, in practice since in a Xen system Qemu > doesn't deal with CPU instructions these other targets will be much > more like each other than (say) i386 is close to m68k. > > Or to put it all another way: from the point of view of Qemu, Xen is > a weird kind of cpu architecture whose instruction emulation is done > "by magic" and Qemu doesn't need to care vary much about that. I don't see how this is so different from KVM, which is integrated to QEMU cleanly. Even if the changes would be more invasive that way (like the memory changes which KVM hasn't done so far), I'd still think that would be better for everyone than having two versions of the same code with some changes. They would eventually drift apart.