From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: xend leaks/bugs/etc Date: Wed, 20 Apr 2005 09:16:11 -0500 Message-ID: <4266642B.1060609@us.ibm.com> References: <1113804011.9189.46.camel@multivac> <1113834723.7086.87.camel@localhost> <4263CF05.2030906@us.ibm.com> <1113838055.7546.6.camel@localhost.localdomain> <4263D624.4040906@us.ibm.com> <1113840962.9390.3.camel@localhost.localdomain> <1113847280.29882.1.camel@localhost> <1113846797.9390.15.camel@localhost.localdomain> <4266007F.2060405@diku.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4266007F.2060405@diku.dk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jacob Gorm Hansen Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org Jacob Gorm Hansen wrote: > Hollis Blanchard wrote: > >> When the ring queue overflows, console data will be dropped, which is >> significant. I notice you avoided the subject of a shared-memory video >> protocol: in that case, dropped data could leave parts of the screen >> obsolete. > > > The same thing happens on a VGA console today, lets not make things > harder in Xen than they are in real life. If you want to be sure that > you see everything (human operator reading bandwidth is also fairly > limited btw.) setup a system which logs stuff to a file inside the VM. It's a bit more complex it we every support 3D acceleration. We can't really throttle that without losing portion of whatevers drawn. For a normal, non-acceleration 2D shared-memory video driver, I imagine it will look a lot like RFB so it will be very easy to control how much work dom0 has to do without losing any quality. > Jacob >