From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: QEMU-KVM and video performance Date: Wed, 21 Apr 2010 19:53:22 +0100 Message-ID: <20100421185322.GN27575@shareable.org> References: <4BCEBE5C.4020404@redhat.com> <20100421183357.GK27575@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Gerhard Wiesinger Return-path: Received: from mail2.shareable.org ([80.68.89.115]:38968 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756185Ab0DUSxj (ORCPT ); Wed, 21 Apr 2010 14:53:39 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Gerhard Wiesinger wrote: > >>Would it be possible to handle these writes through QEMU directly > >>(without > >>KVM), because performance is there very well (looking at the code there > >>is some pointer arithmetic and some memory write done)? > > > >I've noticed extremely slow VGA performance too, when installing OSes. > >It makes the difference between installing in a few minutes, and > >installing taking hours - just because of the slow VGA. > > > >So generally I use qemu for installing old versions of Windows, then > >change to KVM to run them after installing. > > > >Switching between KVM and qemu automatically based on guest code > >behaviour, and making both memory models and device models compatible > >at run time, is a difficult thing. I guess it's not worth the > >difficulty just to speed up VGA. > > I think this is very easy to distingish: > 1.) VGA Segment A000 is legacy and should be handled through QEMU > and not through KVM (because it is much more faster). Also 16 color modes > should be fast enough there. > 2.) All other flat PCI memory accesses should be handled through KVM > (there is a specialized driver loaded for that PCI device in the non > legacy OS). > > Is that easily possible? No it isn't. Distingushing addresses is trivial. You've ignored the hard part, which is switching between different virtualisation architectures... -- Jamie