From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ISrp0-0001E1-7R for qemu-devel@nongnu.org; Wed, 05 Sep 2007 06:09:18 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ISroy-0001D7-Oy for qemu-devel@nongnu.org; Wed, 05 Sep 2007 06:09:17 -0400 Received: from mx1.polytechnique.org ([129.104.30.34]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ISrox-0007S6-OV for qemu-devel@nongnu.org; Wed, 05 Sep 2007 06:09:16 -0400 Received: from [172.17.17.9] (gw.netgem.com [195.68.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTP id 7429433170 for ; Wed, 5 Sep 2007 12:08:27 +0200 (CEST) Message-ID: <46DE8017.50007@bellard.org> Date: Wed, 05 Sep 2007 12:08:23 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Patches from PyQemu project References: <1aa37d910709020650v7c491985r761886db64435ac0@mail.gmail.com> <1188852253.10151.3.camel@squirrel> <46DDB893.2060403@charter.net> <20070904222715.GB9977@networkno.de> <1188949543.6627.14.camel@squirrel> In-Reply-To: <1188949543.6627.14.camel@squirrel> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: > On Tue, 2007-09-04 at 23:27 +0100, Thiemo Seufer wrote: > >>Brian Johnson wrote: >>[snip] >> >>>>My initial thought is to make the libraries at the individual device >>>>level. >>> >>>It would be good to have a general mechanism for bus providers, interrupts, >>>APICs, chipsets, etc. as well, so we could emulate fancier architectures >>>than a simple PC (or simple Sparc/MIPS/ARM/etc. box.) For instance, I'd >>>like to emulate multiple PCIe host bridges, each with an APIC and multiple >>>cards, which might contain PCI-to-PCI bridges. And I'd like to emulate >>>NUMA systems with many memory controllers and a complex memory map, with >>>multiple sets of chipset registers. I don't expect qemu to do this off the >>>shelf, >> >>Why not? I would like to see better abstracted and more capable device >>emulations in Qemu. >> >> >>>but I'd like to avoid hardcoding PC assumptions into the device >>>libraries, so I can code the fancy machines myself and use the I/O as-is. >> >>Then, what does a librar-ized Qemu device with its hardcoded PC >>assumptions help you? > > > Let me give a very pragmatic answer. Right now, KVM has it's own main > loop which uses a thread per-vcpu. Device IO is handled in the context > of the VCPU that originated the IO. I think there's some desire to move > to an N+1 threading model where the extra thread does things like VGA > scanning, VNC, etc. > > Xen, on the other hand, uses a single thread for everything and doesn't > attempt to model multiple VCPUs within the QEMU process. All IO is > delivered via the same channel. QEMU is strictly used for devices. > > Merging either of these with QEMU's current model would be challenging, > merging both would be extremely challenging b/c the two main loop models > are mutually exclusive. > > However, there's no real trouble merging any of the device emulation > back. KVM doesn't maintain any changes to things like device emulation > (other than some KVM-specific APIC stuff). Xen, on the other hand, > mostly has fixes for some of the devices that haven't been submitted > back to QEMU. Other devices are completely unmodified but are severely > lagging behind the QEMU versions. > > VirtualBox is way different than QEMU of course. A bunch of their > device emulation is pretty close to QEMU though. > > I think device emulation is an independent enough problem that there's a > good chance everyone can agree on a single implementation. While it's a > little more work in QEMU to keep these things as libraries and maintain > an interface, I suspect the benefits outweigh the extra cost in that > it's much more likely we'll see more patches. > > There are useful bits of QEMU that could be widely consumed. Their > nature is such that their interfaces are unlikely to change dramatically > in the future. To me, this just screams "library" :-) I agree with the point that QEMU should be improved so that it is easier to reuse the device model. But I consider that the priority is not to export a library but to improve the existing QEMU C APIs. The goal should be that it is possible to emulate several different CPUs at once with several unrelated buses. Moreover the model should support deterministic simulation. Currently the PCI bus is the closest to what is needed, but even in it there are still some conceptual problems (see the DMA problems which were discussed before). Regarding the other projects, I see no technical reason why the KVM code cannot be merged. QEMU already contains the necessary support code for KQEMU and I see no conceptual difference with KVM. Adding a new main loop for KVM or a new KVM specific CPU is not something I am against. Regards, Fabrice.