[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BA23FE1.5050402@codemonkey.ws>
Date: Thu, 18 Mar 2010 09:59:45 -0500
From: Anthony Liguori <anthony@...emonkey.ws>
To: Ingo Molnar <mingo@...e.hu>
CC: Avi Kivity <avi@...hat.com>,
"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Sheng Yang <sheng@...ux.intel.com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Marcelo Tosatti <mtosatti@...hat.com>,
oerg Roedel <joro@...tes.org>,
Jes Sorensen <Jes.Sorensen@...hat.com>,
Gleb Natapov <gleb@...hat.com>,
Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
project
On 03/18/2010 08:00 AM, Ingo Molnar wrote:
>> [...] kvm in fact knows nothing about vga, to take your last
>> example. [...]
>>
> Look at the VGA dirty bitmap optimization a'ka the KVM_GET_DIRTY_LOG ioctl.
>
> See qemu/kvm-all.c's kvm_physical_sync_dirty_bitmap().
>
> It started out as a VGA optimization (also used by live migration) and even
> today it's mostly used by the VGA drivers - albeit a weak one.
>
> I wish there were stronger VGA optimizations implemented, copying the dirty
> bitmap is not a particularly performant solution. (although it's certainly
> better than full emulation) Graphics performance is one of the more painful
> aspects of KVM usability today.
>
We have to maintain a dirty bitmap because we don't have a paravirtual
graphics driver. IOW, someone needs to write an Xorg driver.
Ideally, we could just implement a Linux framebuffer device, right?
Well, we took that approach in Xen and that sucks even worse because the
Xorg framebuffer driver doesn't implement any of the optimizations that
the Linux framebuffer supports and the Xorg driver does not provide use
the kernel's interfaces for providing update regions.
Of course, we need to pull in X into the kernel to fix this, right?
Any sufficiently complicated piece of software is going to interact with
a lot of other projects. The solution is not to pull it all into one
massive repository. It's to build relationships and to find ways to
efficiently work with the various communities.
And we're working on this with X. We'll have a paravirtual graphics
driver very soon. There are no magic solutions. We need more
developers working on the hard problems.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists