{24593}

8.10.1 Virtual-8086
Mode Extensions
The virtual-8086-mode extensions (VME) enable performance
enhancements for 8086 programs running as protected tasks in
virtual-8086 mode. These extensions are enabled by setting
CR4.VME (bit 0) to 1. The extensions enabled by CR4.VME are:
Virtualizing control and notification of maskable external
interrupts with the EFLAGS VIF (bit 19) and VIP (bit 20)
bits.
Selective interception of software interrupts (INTn
instructions) using the TSS interrupt redirection bitmap
(IRB).
Background. Legacy-8086 programs expect to have full access to
the EFLAGS interrupt flag (IF) bit, allowing programs to enable
and disable maskable external interrupts. When those
programs run in virtual-8086 mode under a multitasking
protected-mode environment, it can disrupt the operating
system if programs enable or disable interrupts for their own
purposes. This is particularly true if interrupts associated with
one program can occur during execution of another program.
For example, a program could request that an area of memory
be copied to disk. System software could suspend the program
before external hardware uses an interrupt to acknowledge that
the block has been copied. System software could subsequently
start a second program which enables interrupts. This second
program could receive the external interrupt indicating that
the memory block of the first program has been copied. If that
were to happen, the second program would probably be
unprepared to handle the interrupt properly.
Access to the IF bit must be managed by system software on a
task-by-task basis to prevent corruption of system resources. In
order to completely manage the IF bit, system software must be
able to interrupt all instructions that can read or write the bit.
These instructions include STI, CLI, PUSHF, POPF, INTn, and
IRET. These instructions are part of an instruction class that is
IOPL-sensitive. The processor takes a general-protection
exception (#GP) whenever an IOPL-sensitive instruction is
executed and the EFLAGS.IOPL field is less than the CPL.
Because all virtual-8086 programs run at CPL=3, system
software can interrupt all instructions that modify the IF bit by
setting IOPL<3.
System software maintains a virtual image of the IF bit for each
virtual-8086 program by emulating the actions of IOPLsensitive
instructions that modify the IF bit. When an external
maskable-interrupt occurs, system software checks the state of
the IF image for the current virtual-8086 program to determine
whether the program is masking interrupts. If the program is
masking interrupts, system software saves the interrupt
information until the virtual-8086 program attempts to reenable
interrupts. When the virtual-8086 program unmasks
interrupts with an IOPL-sensitive instruction, system software
traps the action with the #GP handler.
The performance of a processor can be significantly degraded
by the overhead of trapping and emulating IOPL-sensitive
instructions, and the overhead of maintaining images of the IF
bit for each virtual-8086 program. This performance loss can be
eliminated by running virtual-8086 programs with IOPL set to
3, thus allowing changes to the real IF flag from any privilege
level. Unfortunately, this can leave critical system resources
unprotected.
In addition to the performance problems caused by virtualizing
the IF bit, software interrupts (INTn instructions) cannot be
masked by the IF bit or virtual copies of the IF bit. The IF bit
only affects maskable external interrupts. Software interrupts
in virtual-8086 mode are normally directed to the real mode
interrupt-vector table (IVT), but it can be desirable to redirect
certain interrupts to the protected-mode interrupt-descriptor
table (IDT).
The virtual-8086-mode extensions are designed to support both
external interrupts and software interrupts, with mechanisms
that preserve high performance without compromising
protection. Virtualization of external interrupts is supported
using two bits in the EFLAGS register: the virtual-interrupt flag
(VIF) bit and the virtual-interrupt pending (VIP) bit.
Redirection of software interrupts is supported using the
interrupt-redirection bitmap (IRB) in the TSS.

ну, и т.д. ...

Скажу одно - заблуждаешься. VIF и VIP введены еще с первого пентиума, программная поддержка в ОС от MS введена начиная с четвертой NT, а в линейке 9x фича не используется. И никакого отношения к Long Mode в x86-64 не имеют. Уж поверь. А вопрос в другой ветке я задал правильно - посмотри внимательно насчет "Virtual 8086". И задал автору именно в виду того, что говорится что 64 битные ОС будут широко совместимыми. Вот я и поинтересовался, каким образом, если процессор потерял один из этих самых режимов совместимости в 64 битном режиме.

Неее, это ты заблуждаешься (наверно).

Сейчас есть RM(не интересно), PM32, PM16 и V86.
В К8 появляется новый режим PM64. Он _появляется_ а не замещает какой-нибудь из перечисленных.
Как сейчас (имеющиеся OS) обстоят дела с V86? - процессор (обычно по TSS) переходит в режим, который нужен переключаемой задаче.
Т.е. режимы PM32 и PM16 и V86 сосуществуют независимо и не замечая друг-друга. (например, при работе с MMX/FPU это не так)
Дальше ....
Как у тебя работает префикс 66? - правильно, переключает регистры между режимом default и 'другой' разрядности. Что делает префикс 48? ТО-ЖЕ-САМОЕ.
.... так ... какая есть веская причина не сосущесвовать им 'прозрачно'?
(я о 'совместимом' 64x). .... конечно, из 'mov ax,0' можно сотворить 'mov rax,0',
а вот то-же с R8 вряд-ли получится .... потому они и режутся в 'совместимом' режиме.
Короче, нет никаких препятствий тому, чего ты так упорно ищешь ....




Между "задал" и 'получил' ....

p.s.
Легкий намек - у DEC'овского процессора всегда были 64х регистры ...

serj_ Нет, там появляется НОВЫЙ, третий режим функционирования процессора (до этого их было всего 2 - реальный и защищенный, об SMM помолчим - вероятность написать код для него у меня равен нулю). И этот новый режим функционирования - Long Mode (LME бит). Это ОСОБЫЙ защищенный режим, и существенным становится, то что он НЕ поддерживает Virtual 8086 Mode, а исключительно PM16, PM32 и PM64 и у него принципиально иная страничная организация. Префикс изменения размера операнда на 64 битный операнд (48) относится только к PM64. Не надо мне втирать про него - это совсем совсем другая опера - прикладного уровня.

Собственно я и спорить дальше не буду см. 24593, AMD x86-64 Architecture Programmer's Manual Volume 2: System Programming, page 13. Прочти внимательно Note 3 - узнаешь почему я так волнуюсь

???? всего-то? ....

Фраза " Long mode supports only x86 protected mode. It does not support x86 real mode or virtual-8086 mode" переводится как "режим LONG может быть только в PM, для V86 и RM он недоступен".

Технические документы 'дословно' не переводятся.

И еще - SMI есть обычный RM, впрочем, ты знаешь.

Virtual-8086 mode is enabled by setting the virtual-machine bit
in the EFLAGS register (EFLAGS.VM). EFLAGS.VM can only
be set or cleared when the EFLAGS register is loaded from the
TSS as a result of a task switch, or by executing an IRET...
Virtual-8086 mode is not supported when the processor is
operating in long mode. When long mode is enabled, any
attempt to enable virtual-8086 mode is silently ignored.

т.е. из PM64 нельзя перевести в V86. .... нельзя напрямую.
Если обработчик перываний (и менеджер событий) написан в PM64,
то не доступен ни V86, ни PM16-32.
Если обработчик(и только он) написан на PM32 - проблем нет никаких.

И .... читаю дальше:
All of the legacy x86 task-management features are
supported by the AMD64 architecture in legacy mode, but most
features are not available in long mode. Long mode, however,
requires system software to initialize and maintain certain taskmanagement
resources...............

12.2.5 64-Bit Task State Segment
Although the hardware task-switching mechanism is not
supported in long mode, a 64-bit task state segment (TSS) must
still exist. System software must create at least one 64-bit TSS
for use after activating long mode, and it must execute the LTR
instruction, in 64-bit mode, to load the TR register with a
pointer to the 64-bit TSS that serves both 64-bit-mode programs
and compatibility-mode programs.

Да, а ты себе представляешь, что такое сбросить процессор из Long Mode в Legacy Mode для 64 битной ОС (LME очистить)? Она фактически должна передать управление встроенной 32 разрядной ОС, которая в свою очередь запустит Virtual 8086 приложение. Геморрой еще тот. Заметь - если мы словим прерывание в этот момент - мы должны обратно переключаться на 64 битную ОС (реальные обработчики прерываний и драйверы - все в ней пасутся). То есть и реактивность системы нехило падает.
Или я чего неправильно истолковываю? Может взведенный в 32 битном сегменте кода флажок V86 в EFLAGS и при LME работает? Вряд ли.

... а какая ей зад.... разница, куда переходить по обработке аппаратного прерывания?
Была в long, пришло прерывание - переключилась на менеджер обработчика в PM32, который вызывает сам реальный обработчик по TSS (например long).
Дополнительные накладные расходы на PM32-PM64 мизерные для современных процессоров. (вряд ли больше 100 тактов)



... ну не знаю, так все OS работают.



ты этА, не увлекайся.
Когда я делал task switch в TestMem4, то ... как бы попороще ... это была модель OS (которая благополучно сдохла) .... и эти вопросы изучал весьма внимательно. Накладные расходы на task-switch через TSS достаточно большие, но они _НЕСОИЗМЕРИМЫ_ с прочими накладными расходами при переключении задач(task'ов) из-за мониторинга, очередей, приорететов & etc.
Плюс к тому - стартовый проц. для такой OS 'не хилый' и это мелочь.

(конечно, я не знаю, КАК там у M$ в ее Windows64, сам понимаешь )

От, блин тебе все шуточки Накладные расходы на переключение задачи действительно велики, а вот переключать режим работы процессора (с Legacy на Long, а затем обратно) при каждом аппаратном прерывании и обращении к OC (основная ее логика то у нас в 64 битах), если у нас досовское приложение крутится... Ну я не знаю, неизящно это.

'фигня', поверь.



Насчет изящности и эффективности кода есть хороший пример ...
Думаю, ты согласишься, что OS/2 весьма устойчивая и достаточно эффективная OS? (с учетом времени разработки).
Так вот, в ранних версиях (1х-2х) для совместимости с процессором 286 применялась такая тактика обработки DOS-задач
- переход в RM
- обработка тика времени DOS-задачи
- назад в PM
Учти, переход в RM был _настоящий_, в 286 нет V86.
И ... весьма быстренько работало даже на 286 и с реальной многозадачностью.
К томуж .... у К8 наверняка есть оптимизации перехода PM32-PM64, они же не дебилы и помнят о эффективности кода. Где бы тики на команду посмотреть? - там указывается время переключения состояний.....
Короче - не заморачивайся на времени task-switch.

serj_

В 286 нет V86, также как и возможности переключится из PM в RM. Откуда это взял? PM-операционка, работающая часть времени в настоящем RM - бред какой-то... А как же ОС обратно переключиться в PM? Ведь прога в RM делает ВСЕ ЧТО ХОЧЕТ (вплоть до инициализации своей ОС) и ей дела нет до какой-то вызвашей ее ОС. Пожалуйста ссылку на офиц. доки в студию, а то не верю.

SweetLow
Я действительно не знаю как с Virtual 8086 у AMD64. А то бы сказал. Может у самих AMD'шников спросить? У них какой-то онлайновый "круглый стол" девелоперов на сайте функционирует, типа "задай вопрос специалисту" (вот только регистроваться - морока, да еще из России... пошлют наверняка).

Rashid А это в реале ТАК. Более того, там выполнялся аппаратный сброс (иначе никак - программной возможности нет), работал биос, работало досявое приложение и затем снова переключалось в PM. Так кстати и Windows 3.0 и 3.1 на 286 работают (и на 386, если со специальным ключем запускать).

serj_
И все таки периодически слетала эта схема. И вот, чтобы такого гимора не было, в 386 и ввели АППАРАТНУЮ поддержку досовых задач в PM. А AMD ее взяли и выкосили в нативном (Long Mode) режиме работы процессора

... тут еще вот что - за[цензура] замучаются они делать 'полностью 64х' - ага, ВСЕ ща-же с радостными воплями кинутся переписывать драйверы на PM64! .... ага .... конеЧно ....
Сам понимаешь, Long32 и PM32 совершенно не одно и то-же, точнее сказать - PM64 и Long32 это одно и тоже, как и PM16 и PM32 одно и тоже .... а вот все остальные комбинации ....
Так что ... у M$ просто нет другого выбора, кроме как сделать менеджер прерываний в PM32, так что - не переживай ты по поводу V86 ....

SweetLow
Каким образом происходило переключение в RM? Непонятно. А обратно в PM? На таймере в Dos Vector'ах, что-ли висела часть ОС, которая через n-тиков переводила cpu обратно в PM? Боже, какой изврат, какой изврат! Полно DOS'вских прог, которые прописывают свой обработчик таймера, забывая вложенно вызывать предыдущий. И прм первом же запуске такой DOS-проги ОС настанет каюк. Назвать это "защищенной ОС" язык не повернется... А все-таки, как ОС переводила проц обратно в RM, разве это возможно на 286? Что ты понимаешь под словом "аппаратный сброс "?

Rashid Скажем так, без соответсвующей аппаратной поддержки в принципе невозможно защищенную систему построить.
Я тебе аж две штуки для оригинальной PC AT могу назвать плюс одну для новых(весьма конечно относительно новых) чипсетов.

1. Сброс через контроллер клавиатуры
MOV AL, FEh
OUT 64h, AL
CLI
HLT

2. Сброс через Triple Fault -> тяжелый останов (внешняя схема сбрасывает процессор в этом случае)
ZEROIDT DB 0,0,0,0,0,0
LIDT ZEROIDT
INT 3
CLI
HLT

3. Сброс через порт 92h.
IN AL, 92h
OR AL, 01h
OUT 92h, AL
CLI
HLT

ага, RTFM: http://win32.wp-club.net/html/cpu/80486/ch2.htm

serj_ Мне лично непонятно почему везде пример с контроллером клавиатуры приводится? Тройная ошибка гораздо изящнее с моей точки зрения (да и быстрее она выполняется). Хотя это уже чистая история

... просто я по этой книжке учился PM .... вначале ... но уважительное отношение осталось, хоть и BUG'ов вагон.

По поводу элегантности - один парень делал передачу управления через прерывание DIV/0 и спрашивал - как-бы элегантнее вызывать этот exception...
Если придумаешь - кинь ЛС (я сам додумался )

(виноват, закругляюсь, а то поб'ют)

Если по теме - слушай, AMD откровенно 'лажанулись' с этим LONG!
Тут надо было или делать приемственность с старым софтом ... но тогда нельзя расширить регистры ... ай! ВРАНЬЕ! _МОЖНО_!!
Если обозвать префикс 88h(например) как перевод в другую группу регистров,
то можно было-бы весьма безболезненно НЕделать специальный режим LONG.

Ой, мерзкий грядет период .... long попортит крови .... да и вряд-ли Borland
выпустит "Tasm for K8" - а для меня это болезненно.

serj_ Ну дык. В ветке об атлоне 64 в процессорах я уже высказался ранее на этот счет, можешь посмотреть. Мое мнение - совместимости добивались, но не 100% (а была возможна и она). Чтоб процесс миграции слишком надолго не затянулся
Забудь как приятный но сон , они сейчас либо под Java либо под CLR пишут, почти забили на Native code. Особенности рыночной экономики