i686 quirk for AMD Geode
in [Kernel]
|
Prev: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads
Next: drm/ksm -> s2disk -> resume -> [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
From: Lennart Sorensen on 18 Nov 2009 19:50 On Wed, Nov 18, 2009 at 04:11:22PM -0500, Lennart Sorensen wrote: > Strange how it says that for every value I have tried so far. Makes me > wonder if there is a register somewhere that disables MSR support. > I did find a lockout value but I can't read that one either (which says > it is always readable). I tried doing rdmsr on 0x1810 from grub, and it faults too. cpuid says MSRs are supported, I just can't find any that work. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 23 Nov 2009 14:30 Willy Tarreau <w(a)1wt.eu> writes: > On Wed, Nov 11, 2009 at 09:31:26PM -0800, H. Peter Anvin wrote: >> On 11/11/2009 09:27 PM, Willy Tarreau wrote: >> > >> > Right. However we just noticed that with the KVM emulator, you >> > can make it loop for a long time if you feed it with prefixes >> > only. For instance, write a function which does zillions of 0x66 >> > (data size prefix) then return (0xC3) : 66 66 66 ... 66 C3. >> > >> > This is typically the sort of things we must be very careful about >> > in emulators, because we don't want users to steal large amounts >> > of system CPU time doing nothing. >> > >> >> That is a (serious) bug in the KVM interpreter, and indeed the exact >> kind of issues interpreters tend to have... which is why I'd like one >> piece of code with one set of bugs, and more eyeballs on that one piece >> of code so they can be fixed. > > Well, I could try to work on a fix (basically the same principle as in > mine, with prefix flags), but I simply don't know how to test the code. > I've never experimented with KVM yet and learned it embeds an emulator > for the first time a few days ago in this thread :-/ If it's easy to > make use of it, I'm not opposed to try. 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. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 23 Nov 2009 14:50 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 23 Nov 2009 15:10
"H. Peter Anvin" <hpa(a)zytor.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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |