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] [day] [month] [year] [list]

Message-ID: <m1ws1hdn5t.fsf@fess.ebiederm.org>
Date:	Mon, 23 Nov 2009 12:03:10 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.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

"H. Peter Anvin" <hpa@...or.com> writes:

> 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.

For old applications that we were concerned about in dosemu the masked
modes where you write to multiple frame buffer pages at once with a
single write dominated because on real hardware it is faster.

As I recall if the things were setup so we did not need to trap dosemu
mapped the appropriate frame buffer page directly, so we did not need
to handle that case.

Regardless the point is that if we start emulating rare instructions
with traps I expect we will reach the point where we have inner loops
that we want to emulate entirely instead of taking a multitude of traps.

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