From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L1hNk-0007or-G7 for qemu-devel@nongnu.org; Sun, 16 Nov 2008 08:09:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L1hNk-0007oM-0E for qemu-devel@nongnu.org; Sun, 16 Nov 2008 08:09:40 -0500 Received: from [199.232.76.173] (port=36501 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L1hNj-0007oD-Rn for qemu-devel@nongnu.org; Sun, 16 Nov 2008 08:09:39 -0500 Received: from mx2.redhat.com ([66.187.237.31]:39872) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L1hNj-0001Id-BI for qemu-devel@nongnu.org; Sun, 16 Nov 2008 08:09:39 -0500 Message-ID: <49201B12.70406@redhat.com> Date: Sun, 16 Nov 2008 15:07:30 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c References: <1226527840-14183-1-git-send-email-aliguori@us.ibm.com> <20081114040311.GN2055@shareable.org> <491D4BC8.9090807@redhat.com> <20081114132335.GC11975@shareable.org> In-Reply-To: <20081114132335.GC11975@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; 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: Jamie Lokier Cc: Carsten Otte , Anthony Liguori , Hollis Blanchard , kvm-devel , qemu-devel@nongnu.org, Paul Brook Jamie Lokier wrote: > Avi Kivity wrote: > >> Jamie Lokier wrote: >> >>> But does the fact KVM doesn't use TCG prevent KVM from running some >>> x86 modes correctly? E.g. I gather 16-bit code is run by KVM using >>> VM86 mode, which is not exactly correct. It would be nice to have KVM >>> acceleration but also complete and correct emulation, by switching to >>> TCG for those modes. >>> >> There is work in progress to make 16-bit emulation fully accurate. >> > > Ooh! I want my Windows 95 to run in KVM :-) > I'm curious, how is this planned to work? > > I'm having trouble thinking of how to do it without software emulation > at some stage. > > By emulating all instructions that can't be virtualized. >> Since TCG is not smp-safe, this is very problematic for smp guests. You >> would have to stop virtualization on all vcpus and start tcg on all of >> them. Performance would plummet. >> > > On the other hand, when running on a KVM-capable architecture > combination, it is definitely possible to make TCG smp-safe because > every guest atomic instruction has a corresponding host one. It's > practically a 1:1 instruction mapping on x86, which doesn't have many > atomic instructions. (Maybe harder on other archs). > > Maybe. It's simpler to fix kvm not to require this. I don't want kvm to be tied to qemu; when userspace tells kvm to run a vcpu, it means run the vcpu; not "run the vcpu unless there are some instructions you can't run for some undocumented reason". >> There are ways of mitigating the high mmio cost with kvm. For >> framebuffers, one can allow kvm direct access. For other mmio, there's >> the 'coalesced mmio' support which allows mmio to be batched when this >> does not affect emulation accuracy and latency. >> > > Don't you still have to trap for each MMIO in order to collect the > batch, except for REP instructions? It's the traps which are expensive. > > Fortunately modern hardware tends to use DMA for data intensive > things, and MMIO just to trigger DMA, and initialisation. > In practice things work fine. 16-color modes are slow but only very old software was designed to work with them, so it expected the hardware to be slow. -- error compiling committee.c: too many arguments to function