Thema: MiniOS protecdet Mode

[freecrac]

Sicher, dass sie komplett ignoriert werden? AMD doch wieder teilweise Limits für die Segmente eingeführt. Wobei ich die Details nicht auswendig kenne.

[AMD64 ArchitectureV3.pdf] ....auf der Seite von AMD kann ich dieses PDF leider selber gar nicht mehr finden.
Im PDF findet man folgenden Inhalt:
1.2.1 Summary of Legacy Prefixes
In 64-bit mode, the CS, DS, ES, and SS segment override prefixes are ignored.

Edit: Nun habe ich es gefunden: http://support.amd.com/us/Processor_TechDocs/24594.pdf

Dirk

[freecrac]

Hallo,
ich habe noch nicht ganz mit gekriegt, ob Ihr über das Programm oder über Grundlagen
philosophiert.

Bei den Segment override prefixe geht es u.A. um Grundlagen, aber auch um deinen vorherigen Code wo du Segment override prefixe verwendet hast,
obwohl CS = DS = ES war. Hierbei kann man auch die Segment override prefixe weglassen und dann wird DS benutzt, um die selben Adressen zu erreichen.
Segment override prefixe machen nur dann Sinn, wenn damit verschiedene Segmentadressen angesprochen werden können.

Dirk

[Jidder]

Hier ein Ausschnitt vom Long Mode Programm.

Dein Code sieht besser aus, wenn du ihn in [code]-tags tust statt <asm>. Also [code] vor den Code, und [/code] dahinter. (Oder du klickst auf den Button, der so aussieht:

[erik.vikinger]

Hallo,

AMD doch wieder teilweise Limits für die Segmente eingeführt.

Was echt? Segmente haben wohl doch auch ihre Vorteile.

Es wäre schön wenn dazu mal jemand etwas konkreteres schreiben könnte, wenigstens ein Stichwort zum Suchen, würde mich persönlich echt mal interessieren.

Oder du klickst auf den Button....

Aber dazu muss vorher der Code im Eingabefenster korrekt markiert sein.


Grüße
Erik

[kevin]

Volume 2, 4.2.12 (Data Limit Checks in 64-bit Mode):

In 64-bit mode, data reads and writes are not normally checked for segment-limit violations. When
EFER.LMSLE = 1, reads and writes in 64-bit mode at CPL > 0, using the DS, ES, FS, or SS segments,
have a segment-limit check applied.

This limit-check uses the 32-bit segment-limit to find the maximum allowable address in the top 4GB
of the 64-bit virtual (linear) address space.

[freecrac]

Es wäre schön wenn dazu mal jemand etwas konkreteres schreiben könnte, wenigstens ein Stichwort zum Suchen, würde mich persönlich echt mal interessieren.

http://www.o3one.org/hwdocs/amd64bit/x86-64_overview.pdf

Special Treatment of FS and GS Segments. The FS and GS segment
registers are used by the Windows NT™ operating system to
locate the thread-environment-block (TEB) and processorcontrol-
region (PCR) data structures. The FS and GS segmentoverride
prefixes provide quick access to these data structures
in an otherwise unsegmented (flat address space) operating
system. To facilitate compatible access to these structures, the
FS and GS segment overrides can be used in 64-bit mode.
When FS and GS segment overrides are used in 64-bit mode,
their respective base addresses are used in the effectiveaddress
(EA) calculation. The complete EA calculation then
becomes (FS or GS).base + base + index + displacement.
In 64-bit mode, FS.base and GS.base are expanded to the full
virtual-address size supported by the implementation. The
resultant EA calculation is allowed to wrap across positive and
negative addresses.
In 64-bit mode, FS-segment and GS-segment overrides are not
checked for limit or attributes.
Normal segment loads (MOV to Sreg and POP Sreg) into FS and
GS only load a standard 32-bit base value into the hidden
portion of the segment descriptor register. The base address
bits above the standard 32 bits are cleared to 0. Because the
first implementation of the Hammer family of processors
supports 48 virtual-address bits, a segment-load instruction
loads the base value into the lower 32 address bits and clears
the high 16 bits to 0.
To load all address bits supported by a 64-bit implementation,
the FS.base and GS.base hidden descriptor register fields are
physically mapped to MSRs. Privileged software (CPL=0) can
load all supported virtual-address bits into FS.base or GS.base
using a single WRMSR instruction. The FS.base MSR index is
C000_0100h while the GS.base index is C000_0101h.
The addresses written into the expanded FS.base and GS.base
registers must be in canonical form. A WRMSR instruction that
attempts to write a non-canonical address to those registers
generates a general-protection exception, #GP.
When in compatibility mode, the FS and GS overrides operate
as defined by the legacy x86 architecture regardless of the
value loaded into the upper 32 virtual-address bits of the
hidden descriptor register base field. Compatibility mode
ignores the upper 32 bits when calculating an effective address.

Dirk

[erik.vikinger]

Hallo,


@ freecrac & taljeth :
Danke Euch beiden.
Das mit der Basis-Adresse von FS und GS war mir im wesentlichen bekannt aber das mit dem Limit-Check bei DS, ES, FS und SS (?ist da wirklich auch FS dabei?) war mir neu (darauf zielte auch meine Bitte von vorhin ab).


Grüße
Erik

[Relbmessa]

Hallo Forum,
für die es interessiert, hier nun der ganze Quelltext:
http://pastebin.de/18098
Gruß
Relbmessa

PS
Erst mal 30 Tage

[freecrac]

Zum Abfragen der Tastatur wäre es sinvoll vorher zu schauen ob dort überhaupt etwas im Ausgabebuffer vorhanden ist:

Code: [Auswählen]

         in       al, 64h  ; Tastatur-Status holen
 test     al, 1
 jz  NOKEY         ; wenn keine Taste weiter
 test     al, 20h
 jnz NOKEY         ; wenn PS2-Mouse weiter
 in       al, 60h  ; Tasten-Code holen



NOKEY:




[Relbmessa]

Hallo,
ich arbeite nicht mit Polling sondern mit IRQ.
Maus wird nicht installiert.

Gruß
Relbmessa

[freecrac]

Hallo,
ich arbeite nicht mit Polling sondern mit IRQ.

Ups, jetzt habe ich "isrK" gefunden.

Maus wird nicht installiert.

Gruß
Relbmessa

Ok.

Dirk

[Relbmessa]

Hallo,
kleine Info für die Tester vom PM-Programm.
Es besteht ein kleiner Fehler , der mir erst jetzt aufgefallen ist.

Auf dem ASRockP4i65G Motherboard Intel 865 G Chipset läuft das Programm nur bedingt.
Der IRQ von der KBC wird inaktiv .
Im Moment keine Ahnung warum. Der Rest funktioniert aber wie vorgesehen.

Gruß
Relbmessa

PS
Ist in Arbeit

[Relbmessa]

Hallo,
habe das Problem mit dem IRQ für das ASRock P4i65G Motherboard Intel 865 G und ICH5 Chipsatz gelöst.
Es muß die Locale APIC eingetragen werden.BIT 56-63
Zum Code muß wie im Beispiel Unten,die IO-APIC geladen werden.
Für alle IRQs natürlich auch alle Register wie im Beispiel.
   

Code: [Auswählen]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;IO_APIC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
mov eax, 0xFEC00000
;-------------------------
mov byte [eax],0x10 ;select data register

mov eax, 0xFEC00010
mov dword [eax],0x10020 ;8 bit-16->1 maskiert! ;0x0090 ;Vector (7:0)   10h - FEh   /90h-Clock
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;BEACHTE ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;----------------------------------------------------------------------------------
mov eax, 0xFEC00000
;-------------------------
mov byte [eax],0x12 ;select data register

mov eax, 0xFEC00010
mov dword [eax],0x0021 ;Vector (7:0)   10h - FEh   /91h-Keyboard IRQ1
;--------------------------------------------------------------------------------
;;;;;;;;;BIT 56-63 gibt die empfangende Locale APIC an;;;;;;;;;;;;;;;;;;;;;;;;;;
mov eax, 0xFEC00000
;-------------------------
mov byte [eax],0x13 ;select data register

mov eax, 0xFEC00010
mov dword [eax],0x0100000   ;BIT 56-63  (7:0)   10h - FEh   /91h-Keyboard IRQ1
    ;Hier Locale APIC 1
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Gruß
Relbmessa