--- linux/arch/i386/kernel/vm86.c Sat Jul 27 13:12:38 2002
+++ linux/arch/i386/kernel/vm86.c Sat Jul 27 23:56:27 2002
@@ -317,6 +317,11 @@
regs->eflags &= ~TF_MASK;
}
+static inline void clear_AC(struct kernel_vm86_regs * regs)
+{
+ regs->eflags &= ~AC_MASK;
+}
+
/* It is correct to call set_IF(regs) from the set_vflags_*
* functions. However someone forgot to call clear_IF(regs)
* in the opposite case.
@@ -471,6 +476,7 @@
IP(regs) = segoffs & 0xffff;
clear_TF(regs);
clear_IF(regs);
+ clear_AC(regs);
return;
cannot_handle:
Uses Dos;
Const Code: Array[0..79] Of Byte = (
$89,$e5,$50,$53,$06,$51,$fb,$f4,$cf,$90,$90,$90,$90,$90,$90,$90,
$fb,$f4,$89,$ec,$cf,$90,$90,$90,$90,$90,$90,$90,$90,$90,$90,$90,
$0e,$e8,$02,$00,$89,$ec,$cf,$90,$90,$90,$90,$90,$90,$90,$90,$90,
$cd,$01,$cd,$03,$cd,$08,$cc,$9d,$89,$ec,$cf,$90,$90,$90,$90,$90,
$9c,$fa,$89,$ec,$cf,$90,$90,$90,$90,$90,$90,$90,$90,$90,$90,$90
);
Const FV: Array[0..3] Of Word = ($7002,$7102,$7202,$7302);
Var Buffer: Array[0..40000] Of Char;
Var Index: Word;
Var I: Word;
Procedure BufWrite(S: String);
Var I: Byte;
Begin
For I:=1 To Length(S) Do Begin
Buffer[Index]:=S[I];
Inc(Index);
End;
End;
Procedure Hex(w : Word);
Const
HexKarakterer : Array [0..$F] Of Char =
'0123456789ABCDEF';
Begin
BufWrite(HexKarakterer[Hi(w) Shr 4]+
HexKarakterer[Hi(w) And $F]+
HexKarakterer[Lo(w) Shr 4]+
HexKarakterer[Lo(w) And $F]+
' ');
End;
Procedure MyInt1(Flags, CS, IP, AX, BX, CX, DX, SI, DI, DS, ES, BP: word);
Interrupt;
Begin
Hex(IP);
Hex(MemW[CS:IP]);
Hex(SPtr);
Hex(Flags);
BufWrite('Trace'#13#10);
End;
Procedure MyInt3(Flags, CS, IP, AX, BX, CX, DX, SI, DI, DS, ES, BP: word);
Interrupt;
Begin
Hex(IP);
Hex(MemW[CS:IP]);
Hex(SPtr);
Hex(Flags);
BufWrite('Break'#13#10);
End;
Procedure MyInt8(Flags, CS, IP, AX, BX, CX, DX, SI, DI, DS, ES, BP: word);
Interrupt;
Begin
Port[$20]:=$20;
Hex(IP);
Hex(MemW[CS:IP]);
Hex(SPtr);
Hex(Flags);
BufWrite('Timer'#13#10);
End;
Var S01,S03,S08,S18: Pointer;
Var X,Y,Z: Byte;
Var Regs: Registers;
Var T: Byte;
Begin
WriteLn('Waiting');
Index := 0;
T:=Mem[$40:$6C];
Repeat
InLine($F4);
Until Byte(Mem[$40:$6C]-T) > 42;
WriteLn('Runing tests');
GetIntVec($01,S01);
GetIntVec($03,S03);
GetIntVec($08,S08);
GetIntVec($18,S18);
SetIntVec($01,@MyInt1);
SetIntVec($03,@MyInt3);
SetIntVec($08,@MyInt8);
SetIntVec($18,@Code);
For X:=0 To 3 Do
For Y := 0 To 3 Do
For Z := 1 To 4 Do
Begin
BufWrite('Test'#13#10);
Regs.AX:=FV[X];
Regs.BX:=FV[Y];
Regs.CX:=Ofs(Code[Z*16]);
Regs.ES:=Seg(Code);
Regs.Flags:=$7202;
Intr($18,Regs);
End;
SetIntVec($01,S01);
SetIntVec($03,S03);
SetIntVec($08,S08);
SetIntVec($18,S18);
WriteLn('Printing results');
For I:=0 To Index-1 Do
Write(Buffer[I]);
WriteLn('All done.');
End.
Stas Sergeev wrote:
>
> Hello.
>
> According to this:
> http://support.intel.com/design/intarch/techinfo/Pentium/instrefi.htm#89126
> AC flag is cleared by an INT
> instruction executed in real mode.
> The attached patch implements that
> functionality and solves some
> problems recently discussed in
> dosemu mailing list.
This sounds a little strange to me. AC is in the upper 16 bit
of the EFLAGS register, so it is not saved on an interrupt
where only lower 16 bits is saved. This means that when we
clear it on the interrupt, the value will be lost for good.
I can see the spec says it, so we'd better do that. But does
the spec make any sense? And does the CPU really loose the
AC flag on every interrupt in real mode?
A few other things got me wondering, it says there is tested
for enough space in the stack. Does this mean something like
if (SP<6) trap(); ? If it does, we should change do_int to
actually do this. And how should we actually trap if there
is not enough space for pushing values?
And does this testing apply to other instructions as well?
And it also says the IDT size is tested. But does that
concept even exist in real mode?
And finally, why do we have a 32 bit IRET instruction, but
no 32 bit INT instruction? Is that really correct?
--
Kasper Dupont -- der bruger for meget tid p? usenet.
For sending spam use mailto:[email protected]
or mailto:[email protected]
On Thu, 1 Aug 2002, Kasper Dupont wrote:
> Stas Sergeev wrote:
> >
> > Hello.
> >
> > According to this:
> > http://support.intel.com/design/intarch/techinfo/Pentium/instrefi.htm#89126
> > AC flag is cleared by an INT
> > instruction executed in real mode.
> > The attached patch implements that
> > functionality and solves some
> > problems recently discussed in
> > dosemu mailing list.
>
> This sounds a little strange to me. AC is in the upper 16 bit
> of the EFLAGS register, so it is not saved on an interrupt
> where only lower 16 bits is saved. This means that when we
> clear it on the interrupt, the value will be lost for good.
>
Alignment-check does not exist in real mode. Therefore AC flags
mean nothing. In fact, you can't even access more than 16 bits
of the flags register in real mode, even by playing tricks
(pushf pushes only 16 bits, even if you prefix it with 0x66).
> I can see the spec says it, so we'd better do that. But does
> the spec make any sense? And does the CPU really loose the
> AC flag on every interrupt in real mode?
>
Sure, there is no alignment check in real mode. You can access
anything at any offset and an offset running off the end wraps
back through zero.
> A few other things got me wondering, it says there is tested
> for enough space in the stack. Does this mean something like
> if (SP<6) trap(); ? If it does, we should change do_int to
> actually do this. And how should we actually trap if there
> is not enough space for pushing values?
>
If you execute an INT without enough stack, i.e., the SP
gets pushed through zero, as long as nobody trashed its values,
it will be poped back through zero on the IRET. Obviously a
coding bug, but it will still work.
> And does this testing apply to other instructions as well?
>
> And it also says the IDT size is tested. But does that
> concept even exist in real mode?
>
The IDT actually exists in real mode, and its layout is what
defines the interrupt table starting at offset 0. In fact, when
a BIOS needs to transition from/to/back 16/32/16 mode, it saves
the 16-bit table SIDT, so it can restore it with LIDT later.
> And finally, why do we have a 32 bit IRET instruction, but
> no 32 bit INT instruction? Is that really correct?
>
Int NN only references an interrupt number. In 32-bit mode, it
is a 32-bit interrupt which gets completed with a 32-bit IRET.
That number 'NN', references the entries in an IDT.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
On Thu, 2002-08-01 at 16:15, Richard B. Johnson wrote:
> Alignment-check does not exist in real mode. Therefore AC flags
> mean nothing. In fact, you can't even access more than 16 bits
> of the flags register in real mode, even by playing tricks
> (pushf pushes only 16 bits, even if you prefix it with 0x66).
The kernel using virtual 8086 mode, not real mode. In Virtual 8086 mode
the alignment trap is enforced and honoured.
"Richard B. Johnson" wrote:
>
> On Thu, 1 Aug 2002, Kasper Dupont wrote:
>
> > Stas Sergeev wrote:
> > >
> > > Hello.
> > >
> > > According to this:
> > > http://support.intel.com/design/intarch/techinfo/Pentium/instrefi.htm#89126
> > > AC flag is cleared by an INT
> > > instruction executed in real mode.
> > > The attached patch implements that
> > > functionality and solves some
> > > problems recently discussed in
> > > dosemu mailing list.
> >
> > This sounds a little strange to me. AC is in the upper 16 bit
> > of the EFLAGS register, so it is not saved on an interrupt
> > where only lower 16 bits is saved. This means that when we
> > clear it on the interrupt, the value will be lost for good.
> >
>
> Alignment-check does not exist in real mode. Therefore AC flags
> mean nothing.
Dunno, I didn't verify that.
> In fact, you can't even access more than 16 bits
> of the flags register in real mode, even by playing tricks
> (pushf pushes only 16 bits, even if you prefix it with 0x66).
Ehrm, on my CPU (AMD K6/2) pushf and popf does use all 32 bits
of the flag register when prefixed with 0x66 in real mode. And
the emulation of those instructions in the Linux kernel does
that too. Any documentatin on an implementation doing otherwise?
>
> > I can see the spec says it, so we'd better do that. But does
> > the spec make any sense? And does the CPU really loose the
> > AC flag on every interrupt in real mode?
> >
I just verified, yes the AC flag does get cleared.
>
> Sure, there is no alignment check in real mode. You can access
> anything at any offset and an offset running off the end wraps
> back through zero.
Did you test that with AC enabled?
>
> > A few other things got me wondering, it says there is tested
> > for enough space in the stack. Does this mean something like
> > if (SP<6) trap(); ? If it does, we should change do_int to
> > actually do this. And how should we actually trap if there
> > is not enough space for pushing values?
> >
>
> If you execute an INT without enough stack, i.e., the SP
> gets pushed through zero, as long as nobody trashed its values,
> it will be poped back through zero on the IRET. Obviously a
> coding bug, but it will still work.
That is also what I believed, but the specification obviously
says something else.
>
> > And does this testing apply to other instructions as well?
> >
> > And it also says the IDT size is tested. But does that
> > concept even exist in real mode?
> >
>
> The IDT actually exists in real mode, and its layout is what
> defines the interrupt table starting at offset 0. In fact, when
> a BIOS needs to transition from/to/back 16/32/16 mode, it saves
> the 16-bit table SIDT, so it can restore it with LIDT later.
Does that mean you can setup a 32 bit interrupt table in
real mode????
>
> > And finally, why do we have a 32 bit IRET instruction, but
> > no 32 bit INT instruction? Is that really correct?
> >
>
> Int NN only references an interrupt number. In 32-bit mode, it
> is a 32-bit interrupt which gets completed with a 32-bit IRET.
> That number 'NN', references the entries in an IDT.
I was talking about real mode where it seems we have a
32-bit IRET instruction. At least that is what the kernel
emulates.
--
Kasper Dupont -- der bruger for meget tid p? usenet.
For sending spam use mailto:[email protected]
or mailto:[email protected]
Alan Cox wrote:
>
> On Thu, 2002-08-01 at 16:15, Richard B. Johnson wrote:
> > Alignment-check does not exist in real mode. Therefore AC flags
> > mean nothing. In fact, you can't even access more than 16 bits
> > of the flags register in real mode, even by playing tricks
> > (pushf pushes only 16 bits, even if you prefix it with 0x66).
>
> The kernel using virtual 8086 mode, not real mode. In Virtual 8086 mode
> the alignment trap is enforced and honoured.
Sure, but I guess the kernel is supposed to use virtual 86 mode
to emulate real mode. If it really is true that AC is honoured
in virtual 86 mode but ignored in real mode, then the kernel
should be changed to not enable that flag en virtual 86 mode.
The flag itself should still be simulated using other means.
This would be similar to the use of the use of the VIF flag to
emulate the IF flag. This flag has actually got me wondering:
AFAIR the flag is mentioned in Intel specs, but it looks like
in Linux the flag is implemented 100% in software with no help
from the CPU. Is that correct, or did I miss something?
--
Kasper Dupont -- der bruger for meget tid p? usenet.
For sending spam use mailto:[email protected]
or mailto:[email protected]
On Thu, 2002-08-01 at 16:55, Kasper Dupont wrote:
> This would be similar to the use of the use of the VIF flag to
> emulate the IF flag. This flag has actually got me wondering:
> AFAIR the flag is mentioned in Intel specs, but it looks like
> in Linux the flag is implemented 100% in software with no help
> from the CPU. Is that correct, or did I miss something?
The kernel itself doesn't use the alignment flags but some applications
do. For example some language systems use alignment traps for
typechecking by adding a type code (0-3) to the address and
dereferencing it
Alan Cox wrote:
>
> On Thu, 2002-08-01 at 16:55, Kasper Dupont wrote:
> > This would be similar to the use of the use of the VIF flag to
> > emulate the IF flag. This flag has actually got me wondering:
> > AFAIR the flag is mentioned in Intel specs, but it looks like
> > in Linux the flag is implemented 100% in software with no help
> > from the CPU. Is that correct, or did I miss something?
>
> The kernel itself doesn't use the alignment flags but some applications
> do. For example some language systems use alignment traps for
> typechecking by adding a type code (0-3) to the address and
> dereferencing it
Ehrm, that wasn't my point. My point was that if the feature exist
in virtual 86 mode but not in real mode, the kernel should prevent
it from being used in virtual 86 mode because it is supposed to
emulate real mode.
--
Kasper Dupont -- der bruger for meget tid p? usenet.
For sending spam use mailto:[email protected]
or mailto:[email protected]
On Thu, 1 Aug 2002, Kasper Dupont wrote:
> This sounds a little strange to me. AC is in the upper 16 bit
> of the EFLAGS register, so it is not saved on an interrupt
> where only lower 16 bits is saved. This means that when we
> clear it on the interrupt, the value will be lost for good.
Indeed.
> I can see the spec says it, so we'd better do that. But does
> the spec make any sense? And does the CPU really loose the
> AC flag on every interrupt in real mode?
The flag is cleared as on every interrupt regardless of the processor's
mode. It's unfortunate it gets stored nowhere in the real mode, indeed.
It leads the Intel's official CPU determination code to fail if interrupts
are enabled and one arrives at a wrong time. I discovered it in mid-90's
and have some diagnostic code somewhere in my archive -- basically raising
the 8254 timer interrupt rate (actually any IRQ suffices, but that's the
easiest to reconfigure) much enough assures any i486+ processor will get
misidentified as an i386 with high enough probability you may actually see
incorrect reports from programs.
The discussion may be available from a Usenet archive; I think there is a
statement on the problem somewhere at the http://www.x86.org site as well.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Thu, 2002-08-01 at 17:21, Kasper Dupont wrote:
> Ehrm, that wasn't my point. My point was that if the feature exist
> in virtual 86 mode but not in real mode, the kernel should prevent
> it from being used in virtual 86 mode because it is supposed to
> emulate real mode.
That would prevent people wanting to run real virtualised 8086 stuff
that does use the AC trap, and other vm86 extensions to the basic real
mode stuff.
If you want an accurate real mode emulation you are stuck with Bochs,
not down to the kernel but down to the fact vm86 is a mode for running
8086 applications under a 32bit system, not a mode for emulation of real
mode.
On Thu, 1 Aug 2002, Kasper Dupont wrote:
> Ehrm, that wasn't my point. My point was that if the feature exist
> in virtual 86 mode but not in real mode, the kernel should prevent
> it from being used in virtual 86 mode because it is supposed to
> emulate real mode.
The mode is supposed to emulate an 8086 which doesn't have the flag.
Everything else that is available in the mode is a pure implementation
property -- disabling the logic involved is simply not justified by any
means. Any "real mode" code that operates on the AC flag must have been
created after i386 was released as it requires 32-bit instructions. Hence
it has to be prepared to deal with the vm86 mode.
The AC flag doesn't work unless the AM flag is set in cr0 anyway, so
full real mode compatibility may be implemented in software here if
desired.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
"Maciej W. Rozycki" wrote:
>
> On Thu, 1 Aug 2002, Kasper Dupont wrote:
>
> > Ehrm, that wasn't my point. My point was that if the feature exist
> > in virtual 86 mode but not in real mode, the kernel should prevent
> > it from being used in virtual 86 mode because it is supposed to
> > emulate real mode.
>
> The mode is supposed to emulate an 8086 which doesn't have the flag.
OK, but if it is only supposed to emulate an 8086 shouldn't it have
trapped on every instruction not existing on 8086? It doesn't and
that is quite fortunate, because we can then use it for other purposes
namely runing software that expects to have the entire computer for
itself in a multitasking environment. However it seems no matter how
we do it, what is emulated will not work exactly like any CPU in real
mode.
> Any "real mode" code that operates on the AC flag must have been
> created after i386 was released as it requires 32-bit instructions. Hence
> it has to be prepared to deal with the vm86 mode.
That does make some sense, but not all software written for i386 and
later processors does deal with vm86 in the desired way. Some software
was only intended for real mode when being written, but we might now
want to run it in virtual 86 mode. Thanks to emm386 we probably don't
see many DOS programs not working in virtual 86 mode, but emm386 itself
plain refuses to load in virtual 86 mode.
--
Kasper Dupont -- der bruger for meget tid p? usenet.
For sending spam use mailto:[email protected]
or mailto:[email protected]
On Thu, 1 Aug 2002, Kasper Dupont wrote:
[SNIPPED...]
> want to run it in virtual 86 mode. Thanks to emm386 we probably don't
> see many DOS programs not working in virtual 86 mode, but emm386 itself
> plain refuses to load in virtual 86 mode.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
But of course! It's a 32-bit 'trap program', they runs your whole
computer in VM86 mode, paging in memory from above 1 megabyte to
some 'window' below 1 megabyte.
Any attempt to load it cause a trap to Linux when the PE bit is
attempted to be set.
You don't need emm386 because Linux emulates its functionality.
For instance, here is my CONFIG.EMU (like CONFIG.SYS) when VM86
boots DOS on one of my Linux machines.
Note all the wonderful load-high commands.
BUFFERS=16,0
FILES=20
DOS=UMB
LASTDRIVE=F
FCBS=6,0
[menu]
menuitem=BRADLEYNE, Start the TCP/IP Network (NE* Bradley's code)
menuitem=TCPIP, Start the TCP/IP Network (3COM Board PCTCP)
menuitem=BRADLEY, Start the TCP/IP Network (3COM Board ANALOGIC)
menuitem=NDIS_ONLY, Load NDIS driver only (3COM Board)
menuitem=NO_NETWORK, Do not load any network
menuitem=NO_AUTOEXEC, Do not execute any AUTOEXEC.BAT commands
menuitem=DO_HOST, Start RCCS Host Software
menucolor=7,1
menudefault=NO_NETWORK, 4
[SETUP]
DOS=HIGH
STACKS=0,0
BREAK=ON
Rem DEVICE=C:\DOS\SETVER.EXE
SHELL=C:\DOS\COMMAND.COM C:\DOS\ /E:768 /p
[LINUX]
INSTALL=C:\JBOOT\JBOOT.COM C:\JBOOT\VMLINUX
[TCPIP]
INCLUDE=SETUP
DEVICE=C:\USNET\PROTMAN.SYS /I:C:\3COM
DEVICE=C:\3COM\EL90X.DOS
Rem DEVICE=C:\3COM\EL59X.DOS
DEVICE=C:\USNET\BRADLEY.SYS
INSTALL=C:\USNET\NETBIND.EXE
DEVICE=C:\PCTCP\DIS_PKT.GUP
Set TCPIP=TRUE
[DO_HOST]
INCLUDE=SETUP
DEVICE=C:\USNET\PROTMAN.SYS /I:C:\3COM
DEVICE=C:\3COM\EL90X.DOS
DEVICE=C:\USNET\BRADLEY.SYS
INSTALL=C:\USNET\NETBIND.EXE
DEVICE=C:\PCTCP\DIS_PKT.GUP
Set PCTCP=C:\PCTCP\PCTCP.INI
Set FTP_ETC=C:\PCTCP
Set COMSPEC=C:\DOS\COMMAND.COM
Set DEBUG=C:\DOS\DEBUG.EXE
Set PATH=C:\DOS
INSTALL=C:\PCTCP\ETHDRV.EXE
INSTALL=D:\PROJECT\HOSTSYS\HOST\TCPIP.EXE
Set RELOAD=TRUE
[BRADLEY]
INCLUDE=SETUP
DEVICE=C:\USNET\PROTMAN.SYS /I:C:\3COM
DEVICEHIGH /L:1,43648 =C:\3COM\EL90X.DOS
DEVICEHIGH /L:2,800 =C:\USNET\BRADLEY.SYS
INSTALL=C:\USNET\NETBIND.EXE
Set BRADLEY=TRUE
[BRADLEYNE]
INCLUDE=SETUP
DEVICE=C:\USNET\PROTMAN.SYS /I:C:\NETCARD
DEVICE=C:\NETCARD\LM8634.DOS
DEVICE=C:\USNET\BRADLEY.SYS
INSTALL=C:\USNET\NETBIND.EXE
Set BRADLEY=TRUE
[NDIS_ONLY]
INCLUDE=SETUP
DEVICE=C:\USNET\PROTMAN.SYS /I:C:\3COM
Rem DEVICE=C:\3COM\EL59X.DOS
DEVICE=C:\3COM\EL90X.DOS
DEVICE=C:\USNET\BRADLEY.SYS
INSTALL=C:\USNET\NETBIND.EXE
[NO_NETWORK]
INCLUDE=SETUP
[NO_AUTOEXEC]
INCLUDE=SETUP
Set AUTO=FALSE
[DRIVER]
INCLUDE=SETUP
DEVICE=E:\DRIVER\COMLINK.BIN
[common]
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
"Richard B. Johnson" wrote:
>
> On Thu, 1 Aug 2002, Kasper Dupont wrote:
> [SNIPPED...]
>
> > want to run it in virtual 86 mode. Thanks to emm386 we probably don't
> > see many DOS programs not working in virtual 86 mode, but emm386 itself
> > plain refuses to load in virtual 86 mode.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> But of course! It's a 32-bit 'trap program', they runs your whole
> computer in VM86 mode, paging in memory from above 1 megabyte to
> some 'window' below 1 megabyte.
>
> Any attempt to load it cause a trap to Linux when the PE bit is
> attempted to be set.
>
> You don't need emm386 because Linux emulates its functionality.
Sure, if you just want to run DOS and DOS programs you could do
better than using emm386. But if you are actually tring to
emulate a PC, it should have been able to load emm386 without
emm386 even noticing the difference. I guess this just proves
that vm86 isn't well suited for a complete emulation.
IMHO nowadays a reasonable requirement for a good architecture
is that it can easily emulate itself. I guess from that point of
view x86 is not a good architecture, but that shouldn't stop us
from trying to get as close as possible.
--
Kasper Dupont -- der bruger for meget tid p? usenet.
For sending spam use mailto:[email protected]
or mailto:[email protected]