linux-kernel - Re: i686 quirk for AMD Geode

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: <4B0AE3E4.9020909@zytor.com>
Date:	Mon, 23 Nov 2009 11:35:00 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Willy Tarreau <w@....eu>,
	Matt Thrailkill <matt.thrailkill@...il.com>,
	Ingo Molnar <mingo@...e.hu>, Pavel Machek <pavel@....cz>,
	Avi Kivity <avi@...hat.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matteo Croce <technoboy85@...il.com>,
	Sven-Haegar Koch <haegar@...net.de>,
	linux-kernel@...r.kernel.org
Subject: Re: i686 quirk for AMD Geode

On 11/23/2009 11:27 AM, Eric W. Biederman wrote:
> 
> When working on dosemu and emulating EGA 16 color graphics we had to
> unmap the frame buffer so we would cause move instructions to fault.
> Trapping for each mov instruction in the loops that wrote to the frame
> buffer was unusably slow.  Ultimately that was fixed by trapping on
> the first instruction and then running in the emulator until we had
> gone N instructions without hitting an instruction we would trap for.
> The result was usable software emulated EGA graphics.
> 
> I expect the same logic will apply any time there is a trapped and
> emulated instruction in an inner loop.  Emulating the entire loop
> will be more efficient than trapping for each loop iteration.
> 

Yes, this is pretty typical.  In terms of EGA/VGA it depends heavily on
how the application is coded, since it is possible to put EGA/VGA into
modes where the frame buffer depends mostly like memory except at
specific I/O points, and other modes where the frame buffer behaves
nothing like memory at all and every reference needs to be handled
specially.  In real use, the former tends to dominate simply because
it's the sane way to code, but the only way to make the latter perform
sanely at all is to interpret everything.

	-hpa
--
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/