From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: Vmware crashes if compress/misc.c scrolls? Date: Wed, 20 Jun 2007 17:17:02 -0700 Message-ID: <4679C37E.5020908@zytor.com> References: <4679BBCB.2000202@zytor.com> <4679C152.8070407@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4679C152.8070407@goop.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Jeremy Fitzhardinge Cc: Virtualization Mailing List List-Id: virtualization@lists.linuxfoundation.org Jeremy Fitzhardinge wrote: >> First of all, is this actually true? This seems like a monumental >> screwup. >> > > Yes. Is this a report of observed failure? And how would VMWare even > go about implementing this kind of misfeature? Maybe it fails with > particular instructions reading the framebuffer? It supposedly is. >> Second, assuming it is true, what should be done about it? The notion >> that the bootloader should erase the screen is ridiculous since we spend >> a lot of effort maintaining the screen context from 16-bit code. >> >> I see a couple of options: >> > > Maintain a shadow framebuffer, and copy it to the real framebuffer on > update... How would you populate the shadow framebuffer? Pass it in from real mode? -hpa