Hi all,

Is it safe to say that all segment registers under
Windows & Linux are set to zero? For instance,
if I temporarily had to use ESP or EBP as a
data pointer, I wouldn't need to prefix it with DS:,
would I?

Thanks.

Noop wrote:
> Hi all,
> 
> Is it safe to say that all segment registers under
> Windows & Linux are set to zero?

Well... not exactly... They're set to a selector (zero would be an 
invalid selector!), which references a descriptor - not all the same 
one, but all have their "base" set to zero (and their "limit" set to 
4G-1). There's an exception to that. Windows apparently uses fs for 
"thread local storage". I think I've seen similar code in recent Linux. 
I ASSume that this would contain a selector pointing to a descriptor 
whose "base" was non-zero (and whose "limit" was smaller?), but I'm not 
sure on that part.

 > For instance,
> if I temporarily had to use ESP or EBP as a
> data pointer, I wouldn't need to prefix it with DS:,
> would I?

Right. Nor worry about the destination of the "string" instructions 
being es:edi. You can safely assume that ds:, es:, ss:, and cs: refer to 
the same memory. We can *almost* forget they exist... (ain't that nice?!)

Best,
Frank

"Noop" <questioner_x@nospicedham.yahoo.com> wrote in message 
news:3463905d-dd92-4f5c-8894-0afe73196374@z4g2000yqa.googlegroups.com...
> Hi all,
>
> Is it safe to say that all segment registers under
> Windows & Linux are set to zero? For instance,
> if I temporarily had to use ESP or EBP as a
> data pointer, I wouldn't need to prefix it with DS:,
> would I?
>

they have a conceptual base of 0, but the segments are not themselves 0...

0 is a special reserved value for segments, and setting a segment to this 
value makes it unusable (it can be compared to a NULL pointer).


think of it more this way (for 32-bit x86):
CS: ring=3, base=0, limit=4GB, type=32-bit code
DS: ring=3, base=0, limit=4GB, type=32-bit data
DS=ES=SS


segments are actually offsets into a table known as the GDT, which holds a 
bunch of info WRT a particular segment (base, limit, type, ...). when 
loading a segment register, this info is grabbed from this table.


now, FS and GS are special, in that they have a base!=0 amd typically a 
small limit, and are used by OS's to refer to thread-local state 
(thread-local vars, ...).

Win32 uses FS for a TIB/TEB structure.
Win64 uses GS for a TEB with a different layout.
Linux AFAIK uses GS but with a non-fixed layout (depends on OS version...).


in x86-64, CS/DS/ES/SS have to have a base of 0, and the limit is ignored.
FS and GS then are special in that they are the only segments which can 
still have a base!=0.


I am not sure if valid, but I had heard some rumors of the possibility of 
re-adding segment base/limit support to long-mode, but I am not certain as 
to this (nor as to what exactly this would do to the GDT, though it may be 
similar to what has happened to the IDT). but, I don't know...

On Mon, 29 Mar 2010 10:21:42 -0400
Frank Kotler <fbkotler@nospicedham.myfairpoint.net> wrote:

> Noop wrote:
> > Hi all,
> > 
> > Is it safe to say that all segment registers under
> > Windows & Linux are set to zero?
> 
> Well... not exactly... They're set to a selector (zero would be an 
> invalid selector!), which references a descriptor - not all the same 
> one, but all have their "base" set to zero (and their "limit" set to 
> 4G-1). There's an exception to that. Windows apparently uses fs for 
> "thread local storage". I think I've seen similar code in recent
> Linux. I ASSume that this would contain a selector pointing to a
> descriptor whose "base" was non-zero (and whose "limit" was
> smaller?), but I'm not sure on that part.
> 

In 64 bit mode isn;t it that all segment registers are set to zero,
except FS and GS? An if you want to set some other value
in FS and GS they automatically are set to zero?
All in all I would be interested if it is possible to set up
segments in Linux or Windows and program like before,
think segmented. It is said that design of HLL influences,
that you can;t do segments in 32 bit env.
As I understand there are two pointers LDT and GDT,
and they point to segments table , so when you load
segment register they represent index in that table.
Ok, GDT is protected by OS but LDT can be used
by application or is it either protected?

Greets!


-- 
http://maxa.homedns.org/

Sometimes online sometimes not

On Mar 29, 7:46=A0am, "cr88192" <cr88...@hotmail.com> wrote:
> "Noop" <questione...@nospicedham.yahoo.com> wrote in message
>
> news:3463905d-dd92-4f5c-8894-0afe73196374@z4g2000yqa.googlegroups.com...
>
> > Hi all,
>
> > Is it safe to say that all segment registers under
> > Windows & Linux are set to zero? For instance,
> > if I temporarily had to use ESP or EBP as a
> > data pointer, I wouldn't need to prefix it with DS:,
> > would I?
>
> they have a conceptual base of 0, but the segments are not themselves 0..=
..

They (the segment selectors loaded into segment registers) are almost
certainly not NULL in 64-bit mode in Windows and Linux...

> 0 is a special reserved value for segments, and setting a segment to this
> value makes it unusable (it can be compared to a NULL pointer).

....but they can be set to NULL selectors and be usable. AFAIR, in the
kernel mode only, though, but you can check the documentation for
conditions/details. AFAIR from testing, in 64-bit mode any loadable
selector (the restrictions are very very similar to non-64-bit
protected mode except now NULL selectors are OK too under certain
conditions) is usable for *all* accesses once the selector is loaded
(i.e. you can write through a code selector loaded into DS,ES,FS,GS or
a readable data segment selector).

Alex

On Mon, 29 Mar 2010 10:23:31 -0700 (PDT)
"Alexei A. Frounze" <alexfrunews@gmail.com> wrote:

> On Mar 29, 7:46=C2=A0am, "cr88192" <cr88...@hotmail.com> wrote:
> > "Noop" <questione...@nospicedham.yahoo.com> wrote in message
> >
> > news:3463905d-dd92-4f5c-8894-0afe73196374@z4g2000yqa.googlegroups.com...
> >
> > > Hi all,
> >
> > > Is it safe to say that all segment registers under
> > > Windows & Linux are set to zero? For instance,
> > > if I temporarily had to use ESP or EBP as a
> > > data pointer, I wouldn't need to prefix it with DS:,
> > > would I?
> >
> > they have a conceptual base of 0, but the segments are not
> > themselves 0...
>=20
> They (the segment selectors loaded into segment registers) are almost
> certainly not NULL in 64-bit mode in Windows and Linux...
>=20
> > 0 is a special reserved value for segments, and setting a segment
> > to this value makes it unusable (it can be compared to a NULL
> > pointer).
>=20
> ...but they can be set to NULL selectors and be usable. AFAIR, in the
> kernel mode only, though, but you can check the documentation for
> conditions/details. AFAIR from testing, in 64-bit mode any loadable
> selector (the restrictions are very very similar to non-64-bit
> protected mode except now NULL selectors are OK too under certain
> conditions) is usable for *all* accesses once the selector is loaded
> (i.e. you can write through a code selector loaded into DS,ES,FS,GS or
> a readable data segment selector).
>=20
> Alex

Alexei please explain following from Intel manual , as I really
can;t interpret how 64 bit mode works.

"
2.2 MODES OF OPERATION
The IA-32 supports three operating modes and one quasi-operating mode:
=E2=80=A2 Protected mode =E2=80=94 This is the native operating mode of the=
 processor. It
provides a rich set of architectural features, flexibility, high performanc=
e and
backward compatibility to existing software base.
=E2=80=A2 Real-address mode =E2=80=94 This operating mode provides the prog=
ramming
environment of the Intel 8086 processor, with a few extensions (such as the
ability to switch to protected or system management mode).
=E2=80=A2 System management mode (SMM) =E2=80=94 SMM is a standard architec=
tural feature
in all IA-32 processors, beginning with the Intel386 SL processor. This mode
provides an operating system or executive with a transparent mechanism for
implementing power management and OEM differentiation features. SMM is
entered through activation of an external system interrupt pin (SMI#), which
generates a system management interrupt (SMI). In SMM, the processor
switches to a separate address space while saving the context of the curren=
tly
Vol. 3A 2-11
SYSTEM ARCHITECTURE OVERVIEW
running program or task. SMM-specific code may then be executed transparent=
ly.
Upon returning from SMM, the processor is placed back into its state prior =
to the
SMI.
=E2=80=A2 Virtual-8086 mode =E2=80=94 In protected mode, the processor supp=
orts a quasioperating
mode known as virtual-8086 mode. This mode allows the processor
execute 8086 software in a protected, multitasking environment.
Intel 64 architecture supports all operating modes of IA-32 architecture an=
d IA-32e
modes:
=E2=80=A2 IA-32e mode =E2=80=94 In IA-32e mode, the processor supports two =
sub-modes:
compatibility mode and 64-bit mode. 64-bit mode provides 64-bit linear
addressing and support for physical address space larger than 64 GBytes.
Compatibility mode allows most legacy protected-mode applications to run
unchanged.
"

What is 32 e mode?

Then:
"
4.4.1.1 NULL Segment Checking in 64-bit Mode
In 64-bit mode, the processor does not perform runtime checking on NULL seg=
ment
selectors. The processor does not cause a #GP fault when an attempt is made=
 to
access memory where the referenced segment register has a NULL segment
selector.
"

What does this means?
"
3.2.4 Segmentation in IA-32e Mode
In IA-32e mode of Intel 64 architecture, the effects of segmentation depend=
 on
whether the processor is running in compatibility mode or 64-bit mode. In c=
ompatibility
mode, segmentation functions just as it does using legacy 16-bit or 32-bit
protected mode semantics.
In 64-bit mode, segmentation is generally (but not completely) disabled, cr=
eating a
flat 64-bit linear-address space. The processor treats the segment base of =
CS, DS,
ES, SS as zero, creating a linear address that is equal to the effective ad=
dress. The FS
and GS segments are exceptions. These segment registers (which hold the seg=
ment
base) can be used as an additional base registers in linear address calcula=
tions. They
facilitate addressing local data and certain operating system data structur=
es.
Note that the processor does not perform segment limit checks at runtime in=
 64-bit
mode.
"

Finally:
"
3.4.4 Segment Loading Instructions in IA-32e Mode
Because ES, DS, and SS segment registers are not used in 64-bit mode, their=
 fields
(base, limit, and attribute) in segment descriptor registers are ignored. S=
ome forms
of segment load instructions are also invalid (for example, LDS, POP ES). A=
ddress
calculations that reference the ES, DS, or SS segments are treated as if th=
e segment
base is zero.
The processor checks that all linear-address references are in canonical fo=
rm instead
of performing limit checks. Mode switching does not change the contents of =
the
segment registers or the associated descriptor registers. These registers a=
re also not
changed during 64-bit mode execution, unless explicit segment loads are per=
formed.
In order to set up compatibility mode for an application, segment-load inst=
ructions
(MOV to Sreg, POP Sreg) work normally in 64-bit mode. An entry is read from=
 the
system descriptor table (GDT or LDT) and is loaded in the hidden portion of=
 the
segment descriptor register. The descriptor-register base, limit, and attri=
bute fields
are all loaded. However, the contents of the data and stack segment selecto=
r and the
descriptor registers are ignored.
When FS and GS segment overrides are used in 64-bit mode, their respective =
base
addresses are used in the linear address calculation: (FS or GS).base + ind=
ex +
displacement. FS.base and GS.base are then expanded to the full linear-addr=
ess size
supported by the implementation. The resulting effective address calculatio=
n can
wrap across positive and negative addresses; the resulting linear address m=
ust be
canonical.
In 64-bit mode, memory accesses using FS-segment and GS-segment overrides a=
re
not checked for a runtime limit nor subjected to attribute-checking. Normal=
 segment
loads (MOV to Sreg and POP Sreg) into FS and GS load a standard 32-bit base=
 value
in the hidden portion of the segment descriptor register. The base address =
bits above
the standard 32 bits are cleared to 0 to allow consistency for implementati=
ons that
use less than 64 bits.
The hidden descriptor register fields for FS.base and GS.base are physicall=
y mapped
to MSRs in order to load all address bits supported by a 64-bit implementat=
ion. Software
with CPL =3D 0 (privileged software) can load all supported linear-address =
bits
into FS.base or GS.base using WRMSR. Addresses written into the 64-bit FS.b=
ase and
GS.base registers must be in canonical form. A WRMSR instruction that attem=
pts to
write a non-canonical address to those registers causes a #GP fault.
When in compatibility mode, FS and GS overrides operate as defined by 32-bi=
t mode
behavior regardless of the value loaded into the upper 32 linear-address bi=
ts of the
hidden descriptor register base field. Compatibility mode ignores the upper=
 32 bits
when calculating an effective address.
A new 64-bit mode instruction, SWAPGS, can be used to load GS base. SWAPGS
exchanges the kernel data structure pointer from the IA32_KernelGSbase MSR =
with
the GS base register. The kernel can then use the GS prefix on normal memor=
y references
to access the kernel data structures. An attempt to write a non-canonical v=
alue
(using WRMSR) to the IA32_KernelGSBase MSR causes a #GP fault.
"

This is beat of confusing to me.

Thanks,
Branimir
--=20
http://maxa.homedns.org/

Sometimes online sometimes not

On Mar 29, 9:29=A0pm, Branimir Maksimovic
<bm...@nospicedham.hotmail.com> wrote:
> On Mon, 29 Mar 2010 10:23:31 -0700 (PDT)
> "Alexei A. Frounze" <alexfrun...@gmail.com> wrote:
>
>
>
> > On Mar 29, 7:46=A0am, "cr88192" <cr88...@hotmail.com> wrote:
> > > "Noop" <questione...@nospicedham.yahoo.com> wrote in message
>
> > >news:3463905d-dd92-4f5c-8894-0afe73196374@z4g2000yqa.googlegroups.com.=
...
>
> > > > Hi all,
>
> > > > Is it safe to say that all segment registers under
> > > > Windows & Linux are set to zero? For instance,
> > > > if I temporarily had to use ESP or EBP as a
> > > > data pointer, I wouldn't need to prefix it with DS:,
> > > > would I?
>
> > > they have a conceptual base of 0, but the segments are not
> > > themselves 0...
>
> > They (the segment selectors loaded into segment registers) are almost
> > certainly not NULL in 64-bit mode in Windows and Linux...
>
> > > 0 is a special reserved value for segments, and setting a segment
> > > to this value makes it unusable (it can be compared to a NULL
> > > pointer).
>
> > ...but they can be set to NULL selectors and be usable. AFAIR, in the
> > kernel mode only, though, but you can check the documentation for
> > conditions/details. AFAIR from testing, in 64-bit mode any loadable
> > selector (the restrictions are very very similar to non-64-bit
> > protected mode except now NULL selectors are OK too under certain
> > conditions) is usable for *all* accesses once the selector is loaded
> > (i.e. you can write through a code selector loaded into DS,ES,FS,GS or
> > a readable data segment selector).
>
> > Alex
>
> Alexei please explain following from Intel manual , as I really
> can;t interpret how 64 bit mode works.
>
> "
> 2.2 MODES OF OPERATION
> The IA-32 supports three operating modes and one quasi-operating mode:
> =95 Protected mode =97 This is the native operating mode of the processor=
.. It
> provides a rich set of architectural features, flexibility, high performa=
nce and
> backward compatibility to existing software base.
> =95 Real-address mode =97 This operating mode provides the programming
> environment of the Intel 8086 processor, with a few extensions (such as t=
he
> ability to switch to protected or system management mode).
> =95 System management mode (SMM) =97 SMM is a standard architectural feat=
ure
> in all IA-32 processors, beginning with the Intel386 SL processor. This m=
ode
> provides an operating system or executive with a transparent mechanism fo=
r
> implementing power management and OEM differentiation features. SMM is
> entered through activation of an external system interrupt pin (SMI#), wh=
ich
> generates a system management interrupt (SMI). In SMM, the processor
> switches to a separate address space while saving the context of the curr=
ently
> Vol. 3A 2-11
> SYSTEM ARCHITECTURE OVERVIEW
> running program or task. SMM-specific code may then be executed transpare=
ntly.
> Upon returning from SMM, the processor is placed back into its state prio=
r to the
> SMI.
> =95 Virtual-8086 mode =97 In protected mode, the processor supports a qua=
sioperating
> mode known as virtual-8086 mode. This mode allows the processor
> execute 8086 software in a protected, multitasking environment.
> Intel 64 architecture supports all operating modes of IA-32 architecture =
and IA-32e
> modes:
> =95 IA-32e mode =97 In IA-32e mode, the processor supports two sub-modes:
> compatibility mode and 64-bit mode. 64-bit mode provides 64-bit linear
> addressing and support for physical address space larger than 64 GBytes.
> Compatibility mode allows most legacy protected-mode applications to run
> unchanged.
> "
>
> What is 32 e mode?

Once you've switched the CPU into 64-bit mode, only the following
modes are available:
64-bit
16/32-bit protected (compatibility)
This mode subset is what 32e is. What's different in it is memory,
interrupt and task management, which are done the 64-bit way (you
don't have old-style page tables for non-64-bit modes, task switching
no longer works, etc).

> Then:
> "
> 4.4.1.1 NULL Segment Checking in 64-bit Mode
> In 64-bit mode, the processor does not perform runtime checking on NULL s=
egment
> selectors. The processor does not cause a #GP fault when an attempt is ma=
de to
> access memory where the referenced segment register has a NULL segment
> selector.
> "
>
> What does this means?

That means if you manage to load a NULL selector into a segment
register in 64-bit mode (this is relaxed in 64-bit mode), there will
be no further checks on the selector/segment type after the segment
register load and you will be able to access code/data through it
(which is impossible in 16/32-bit protected mode).

> "
> 3.2.4 Segmentation in IA-32e Mode
> In IA-32e mode of Intel 64 architecture, the effects of segmentation depe=
nd on
> whether the processor is running in compatibility mode or 64-bit mode. In=
 compatibility
> mode, segmentation functions just as it does using legacy 16-bit or 32-bi=
t
> protected mode semantics.
> In 64-bit mode, segmentation is generally (but not completely) disabled, =
creating a
> flat 64-bit linear-address space. The processor treats the segment base o=
f CS, DS,
> ES, SS as zero, creating a linear address that is equal to the effective =
address. The FS
> and GS segments are exceptions. These segment registers (which hold the s=
egment
> base) can be used as an additional base registers in linear address calcu=
lations. They
> facilitate addressing local data and certain operating system data struct=
ures.
> Note that the processor does not perform segment limit checks at runtime =
in 64-bit
> mode.
> "
>
> Finally:
> "
> 3.4.4 Segment Loading Instructions in IA-32e Mode
> Because ES, DS, and SS segment registers are not used in 64-bit mode, the=
ir fields
> (base, limit, and attribute) in segment descriptor registers are ignored.=
 Some forms
> of segment load instructions are also invalid (for example, LDS, POP ES).=
 Address
> calculations that reference the ES, DS, or SS segments are treated as if =
the segment
> base is zero.
> The processor checks that all linear-address references are in canonical =
form instead
> of performing limit checks. Mode switching does not change the contents o=
f the
> segment registers or the associated descriptor registers. These registers=
 are also not
> changed during 64-bit mode execution, unless explicit segment loads are p=
erformed.
> In order to set up compatibility mode for an application, segment-load in=
structions
> (MOV to Sreg, POP Sreg) work normally in 64-bit mode. An entry is read fr=
om the
> system descriptor table (GDT or LDT) and is loaded in the hidden portion =
of the
> segment descriptor register. The descriptor-register base, limit, and att=
ribute fields
> are all loaded. However, the contents of the data and stack segment selec=
tor and the
> descriptor registers are ignored.
> When FS and GS segment overrides are used in 64-bit mode, their respectiv=
e base
> addresses are used in the linear address calculation: (FS or GS).base + i=
ndex +
> displacement. FS.base and GS.base are then expanded to the full linear-ad=
dress size
> supported by the implementation. The resulting effective address calculat=
ion can
> wrap across positive and negative addresses; the resulting linear address=
 must be
> canonical.
> In 64-bit mode, memory accesses using FS-segment and GS-segment overrides=
 are
> not checked for a runtime limit nor subjected to attribute-checking. Norm=
al segment
> loads (MOV to Sreg and POP Sreg) into FS and GS load a standard 32-bit ba=
se value
> in the hidden portion of the segment descriptor register. The base addres=
s bits above
> the standard 32 bits are cleared to 0 to allow consistency for implementa=
tions that
> use less than 64 bits.
> The hidden descriptor register fields for FS.base and GS.base are physica=
lly mapped
> to MSRs in order to load all address bits supported by a 64-bit implement=
ation. Software
> with CPL =3D 0 (privileged software) can load all supported linear-addres=
s bits
> into FS.base or GS.base using WRMSR. Addresses written into the 64-bit FS=
..base and
> GS.base registers must be in canonical form. A WRMSR instruction that att=
empts to
> write a non-canonical address to those registers causes a #GP fault.
> When in compatibility mode, FS and GS overrides operate as defined by 32-=
bit mode
> behavior regardless of the value loaded into the upper 32 linear-address =
bits of the
> hidden descriptor register base field. Compatibility mode ignores the upp=
er 32 bits
> when calculating an effective address.
> A new 64-bit mode instruction, SWAPGS, can be used to load GS base. SWAPG=
S
> exchanges the kernel data structure pointer from the IA32_KernelGSbase MS=
R with
> the GS base register. The kernel can then use the GS prefix on normal mem=
ory references
> to access the kernel data structures. An attempt to write a non-canonical=
 value
> (using WRMSR) to the IA32_KernelGSBase MSR causes a #GP fault.
> "
>
> This is beat of confusing to me.

What exactly is confusing in the above text?
It clearly states that in 64-bit mode:
- segment bases for CS,DS,ES and SS are always 0 (GDT/LDT base fields
are ignored or required to be 0)
- segment bases for FS and GS are taken from the appropriate MSRs
- there are no segment limit checks (except for the offsets being
canonical (that is, limited in number of bits that can be either 0 or
1 (there's some MSR register that says how many bits are available for
the virtual address, which is not 64, but fewer, something like 48)
and being properly sign-extended))
- SWAPGS swaps GS base (previously loaded from GS.Base MSR) with
IA32_KernelGSbase MSR to make it easier/faster to save/restore GS base
- segmentation for 16/32-bit protected (compatibility) mode remains
the same

Alex

On Mon, 29 Mar 2010 23:57:43 -0700 (PDT)
"Alexei A. Frounze" <alexfrunews@nospicedham.gmail.com> wrote:

> 
> What exactly is confusing in the above text?
> It clearly states that in 64-bit mode:
> - segment bases for CS,DS,ES and SS are always 0 (GDT/LDT base fields
> are ignored or required to be 0)
> - segment bases for FS and GS are taken from the appropriate MSRs
> - there are no segment limit checks (except for the offsets being
> canonical (that is, limited in number of bits that can be either 0 or
> 1 (there's some MSR register that says how many bits are available for
> the virtual address, which is not 64, but fewer, something like 48)
> and being properly sign-extended))
> - SWAPGS swaps GS base (previously loaded from GS.Base MSR) with
> IA32_KernelGSbase MSR to make it easier/faster to save/restore GS base
> - segmentation for 16/32-bit protected (compatibility) mode remains
> the same
> 
> Alex

Thanks, they should employ you to write manuals ;)

Greets!


-- 
http://maxa.homedns.org/

Sometimes online sometimes not

On Mar 30, 12:20=A0am, Branimir Maksimovic
<bm...@nospicedham.hotmail.com> wrote:
....
> Thanks, they should employ you to write manuals ;)

According to the perceived quality of their documents (mistakes/typos
per page or their total number per volume) as function of time,
*IMHO*, they've recently been doing everything to make their manuals
more obscure and to cover up bugs. In that case I doubt they want to
employ me or anyone else at least as knowledgeable to diligently write
or correct these manuals. :)

The good thing is, you can cross-check many things with AMD manuals or
simply try something out and see what happens. That's how I've been
coping with the ambiguity of the x86 docs. And that's how I know many
things I know and so can you. :)

Alex

On Mar 29, 11:57=A0pm, "Alexei A. Frounze"
<alexfrun...@nospicedham.gmail.com> wrote:
....
> - there are no segment limit checks (except for the offsets being
> canonical (that is, limited in number of bits that can be either 0 or
> 1 (there's some MSR register that says how many bits are available for
> the virtual address, which is not 64, but fewer, something like 48)
> and being properly sign-extended))

Actually, I think that's not in an MSR, but rather returned by CPUID.

Alex

"Alexei A. Frounze" <alexfrunews@nospicedham.gmail.com> wrote in message 
news:69ba54fd-16e4-4ce2-bdff-aecb8c140c2a@g1g2000pre.googlegroups.com...
On Mar 30, 12:20 am, Branimir Maksimovic
<bm...@nospicedham.hotmail.com> wrote:
....
> Thanks, they should employ you to write manuals ;)

<--
According to the perceived quality of their documents (mistakes/typos
per page or their total number per volume) as function of time,
*IMHO*, they've recently been doing everything to make their manuals
more obscure and to cover up bugs. In that case I doubt they want to
employ me or anyone else at least as knowledgeable to diligently write
or correct these manuals. :)

The good thing is, you can cross-check many things with AMD manuals or
simply try something out and see what happens. That's how I've been
coping with the ambiguity of the x86 docs. And that's how I know many
things I know and so can you. :)
-->


yep, although in a few cases I have seen the same issues in both docs, and 
to me this has seemed suspect...

generally agreed though.

On Mar 30, 1:25=A0am, "Alexei A. Frounze"
<alexfrun...@nospicedham.gmail.com> wrote:
> > Thanks, they should employ you to write manuals ;)
>
> According to the perceived quality of their documents (mistakes/typos
> per page or their total number per volume) as function of time,
> *IMHO*, they've recently been doing everything to make their manuals
> more obscure and to cover up bugs. In that case I doubt they want to
> employ me or anyone else at least as knowledgeable to diligently write
> or correct these manuals. :)
>
> The good thing is, you can cross-check many things with AMD manuals or
> simply try something out and see what happens. That's how I've been
> coping with the ambiguity of the x86 docs. And that's how I know many
> things I know and so can you. :)

Yep. Obviously, they don't even read their own IA-32 documentation.
Maybe they have something better for internal usage, dunno. Until very
recently, their CR0.WP bit description looked like the person who
wrote it was smoking something heavy - one half confusing, the other
half wrong. They eventually fixed it, though (after what, 15 years of
CR0.WP being around?).

My current favorite is the "privileged software exception". Vol. 3B is
chock-full of references to this mysterious exception type, but *what*
it is is never explained anywhere. The horrible truth may be that
Intel has yet to invent exceptions that belong to this type...

On Apr 1, 2:28=A0am, Cyril Novikov <qmbmnp3...@nospicedham.pacbell.net>
wrote:
> My current favorite is the "privileged software exception". Vol. 3B is
> chock-full of references to this mysterious exception type, but *what*
> it is is never explained anywhere. The horrible truth may be that
> Intel has yet to invent exceptions that belong to this type...


Well it certainly has some mysterious aspects!

First, it=92s not an exception in the traditional sense at all:  Rather
it's part of the control of how an exception/interrupt is *injected*
*into* a virtual machine by a hypervisor.  For example, if you were
injecting a (virtual) external interrupt (let's say from the virtual
serial port), you'd do a VM-Entry and specify a type of "External
Interrupt" (along with the interrupt vector number and some other
stuff).

There are distinctions because the way that x86 handles different
types of interrupts/exceptions varies.  For example, injecting an
=93Overflow=94 interrupt (a trap, rather than a fault) requires that the
saved EIP point to the instruction *after* the INTO instruction that
generated the trap, whereas a page fault requires that the saved EIP
point to the faulting instruction (and it also stores a parameter on
the stack detailing the page fault).

Privileged software exceptions don=92t appear to be related to any
particular x86 events (basically everything you might want to inject
is covered under one of the other categories).  I pretty sure they=92re
intended to provide a fast way to communicate from the VMM to a guest
OS with an interrupt-like mechanism.  Of course you *could* just
inject an external interrupt, but that probably ends up requiring
various trips through the APIC emulators, and all sorts of nasty guest
OS code.  The privileged software exceptions are something of a
hybrid, in that they=92re more like the response to an INTx (but without
the privilege checking).

FWIW, Xen doesn=92t use them at all, and some of the VMM-to-guest
interfaces he provides are, in fact, done via something looking
somewhat like a traditional I/O device.