lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100319091904.GF10003@linux-sh.org>
Date:	Fri, 19 Mar 2010 18:19:04 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Anthony Liguori <anthony@...emonkey.ws>
Cc:	Ingo Molnar <mingo@...e.hu>, 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 Thu, Mar 18, 2010 at 11:11:43AM -0500, Anthony Liguori wrote:
> On 03/18/2010 10:17 AM, Ingo Molnar wrote:
> >* Anthony Liguori<anthony@...emonkey.ws>  wrote:
> >>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?
> >>     
> >No, you'd want to interact with DRM.
> 
> Using DRM doesn't help very much.  You still need an X driver and most 
> of the operations you care about (video rendering, window movement, etc) 
> are not operations that need to go through DRM.
> 
> 3D graphics virtualization is extremely difficult in the non-passthrough 
> case.  It really requires hardware support that isn't widely available 
> today (outside a few NVIDIA chipsets).
> 
Implementing a virtualized DRM/KMS driver would at least get you the
framebuffer interface more or less for free, while allowing you to deal
with the userspace side of things incrementally (ie, running a dummy xorg
on top of the virtualized fbdev until the DRI side catches up). It would
also enable you to focus on the 2D and 3D parts independently.

> It doesn't provide the things we need to a good user experience.  You 
> need things like an absolute input device, host driven display resize, 
> RGBA hardware cursors.  None of these go through DRI and it's those 
> things that really provide the graphics user experience.
> 
None of these things negate the benefit one would get from a virtualized
DRM/KMS driver either. There are multiple problems that need solving in
this area, and it's a bit disingenuous to discount a valid suggestion out
of hand due to the fact it doesn't solve all of the outstanding issues.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ