[转载]long mode 模式下 system/gate descriptor 的疑惑

1、 32 位的 system descriptor 与 64 位的 system descriptor

(1)compatibility 模式下,LDT / TSS descriptor 还是原来的 32 位的 descriptor,与原来 x86 的 LDT / TSS 意义一致。 (2)64 bit 模式下,LDT / TSS descriptor 扩展为 64 位的 descriptor。 descriptor 的 type 被相应改烃。由原来的 32 bit-LDT 改为 64 bit-LDT,available/busy 32bit-TSS 改变 available/busy 64bit-TSS。
  一个全新 64 位 OS 在开启和激活 long mode 后 转入 64 bit 模式,在 64 bit 模式下必须使用 LTR 指令来加载 available 64-TSS 来建立一个 64 位的 TSS 环境。available 64-TSS 加载后,被 processor 置为 busy 64-TSS 且不会再置回为 avalilable 64-TSS。   所以,无论是在 compatibility 模式还是在 64 bit 模式,使用的都是 64 位 TSS,但是在 compatibility 模式下 TSS 还是被认为是 32 位的 TSS,其行为如同 x86 下,若在 compatibility 下使用 LTR 指令只能加载 32 位的 TSS。64 bit 下使用 LTR 指令加载的是 64 位的 TSS。在 OS 初始化时,实际上的 TSS 环境是 64 位 TSS。   因此,在 compatibility 下实际上还是使用的是 64 位的 TSS 环境。
  long mode 下不支持 TSS 的任务切换机制,因此,将不支持使用 TSS selector 来 far call 进行任务切换机制。
(3)不能使用 TSS 的任务切换机制,导致了不能加载 LDT 。而 LLDT 指令在 OS 初始化时进行,加载的是 64 位的 LDT。
   2、64 位的 gate(call-gate、interrupt-gate 及 trap gate)
  long mode 下不支持 task gate。在 long mode 模式下,无论是 compatibility 模式还是 64 bit 模式,所有的 gate 都是 64 位的。gate 指向的 code segment 必须是 64 位的 code segment(L = 1 & D = 0)。   在 compatibility 模式下使用 call-gate 来 far call 到 code segment 或者 INT n 调用系统例程。processor 将由 compatibility 模式切换到 64 bit 模式。   在不同权限的 code segment 间执行并改变 CPL 只能通过 gate (call、interrupt/trap)达到,因此 64 位的 OS 核心必定运行在 64 bit 模式下。

时间: 2024-10-18 21:11:39

[转载]long mode 模式下 system/gate descriptor 的疑惑的相关文章

[转载]long mode 模式下的中断服务例程

在 long mode 下,gate 是 16 字节的,并取消了对 task gate 的支持.即 IDT 的 entry 是 16 字节的,所以:gate = IDTR.base + vector * 16. 在 long mode 下,code segment descriptor 的 L.D.C 以及 DPL 有效,其它域无效.由于 base 强制为 0,中断服务例程的入口地址就是 gate.offset,这个 offset 是 64 位值.code segment descriptor

HP 笔记本 UEFI 模式下还原 windows 7 the system image restore failed

本人公司电脑型号为HP folio9740m, 用windows 7自带的修复工具,恢复windows标准镜像文件,出现如下错误: The system image restore failed. Windows cannot restore a system image to a computer than has different firmware. The system image was created on a computer using BIOS and this compute

对于linux下system()函数的深度理解(整理)

对于linux下system()函数的深度理解(整理) (2013-02-07 08:58:54) 这几天调程序(嵌入式linux),发现程序有时就莫名其妙的死掉,每次都定位在程序中不同的system()函数,直接在shell下输入system()函数中调用的命令也都一切正常.就没理这个bug,以为是其他的代码影响到这个,或是内核驱动文件系统什么的异常导致,昨天有出现了这个问题,就随手百了一下度,问题出现了,很多人都说system()函数要慎用要少用要能不用则不用,system()函数不稳定?

Apache Spark源码走读之15 -- Standalone部署模式下的容错性分析

欢迎转载,转载请注明出处,徽沪一郎. 概要 本文就standalone部署方式下的容错性问题做比较细致的分析,主要回答standalone部署方式下的包含哪些主要节点,当某一类节点出现问题时,系统是如何处理的. Standalone部署的节点组成 介绍Spark的资料中对于RDD这个概念涉及的比较多,但对于RDD如何运行起来,如何对应到进程和线程的,着墨的不是很多. 在实际的生产环境中,Spark总是会以集群的方式进行运行的,其中standalone的部署方式是所有集群方式中最为精简的一种,另外

Android KK后为何工厂模式下无法adb 无法重新启动机器 ?

前言 欢迎大家我分享和推荐好用的代码段~~ 声明          欢迎转载,但请保留文章原始出处: CSDN:http://www.csdn.net 雨季o莫忧离:http://blog.csdn.net/luckkof 正文 KK 以后 为何工厂模式下无法adb reboot ? 正常情况下adb reboot 能够重新启动. [Keyword] adb reboot, factory mode, 工厂模式, 工厂模式无法重新启动 [版本号约束] android 4.4,  KK 或者KK

Android KK后为何工厂模式下无法adb 无法重启机器 ?

前言 欢迎大家我分享和推荐好用的代码段~~ 声明          欢迎转载,但请保留文章原始出处: CSDN:http://www.csdn.net 雨季o莫忧离:http://blog.csdn.net/luckkof 正文 KK 以后 为何工厂模式下无法adb reboot ? 正常情况下adb reboot 可以重启. [Keyword] adb reboot, factory mode, 工厂模式, 工厂模式无法重启 [版本约束] android 4.4,  KK 或者KK 以后版本

[老老实实学WCF] 第十篇 消息通信模式(下) 双工

原文:[老老实实学WCF] 第十篇 消息通信模式(下) 双工 老老实实学WCF 第十篇 消息通信模式(下) 双工 在前一篇的学习中,我们了解了单向和请求/应答这两种消息通信模式.我们知道可以通过配置操作协定的IsOneWay属性来改变模式.在这一篇中我们来研究双工这种消息通信模式. 在一定程度上说,双工模式并不是与前面两种模式相提并论的模式,双工模式的配置方法同前两者不同,而且双工模式也是基于前面两种模式之上的. 在双工模式下,服务端和客户端都可以独立地调用对方,谁都不用等待谁的答复,同样也不期

Apache Spark源码走读之19 -- standalone cluster模式下资源的申请与释放

欢迎转载,转载请注明出处,徽沪一郎. 概要 本文主要讲述在standalone cluster部署模式下,Spark Application在整个运行期间,资源(主要是cpu core和内存)的申请与释放. 构成Standalone cluster部署模式的四大组成部件如下图所示,分别为Master, worker, executor和driver,它们各自运行于独立的JVM进程. 从资源管理的角度来说 Master  掌管整个cluster的资源,主要是指cpu core和memory,但Ma

检测到在集成的托管管道模式下不适用的 ASP.NET 设置。

我们将ASP.NET程序从IIS6移植到IIS7,可能运行提示以下错误: HTTP 错误 500.23 - Internal Server Error 检测到在集成的托管管道模式下不适用的 ASP.NET 设置. 为什么会出现以上错误? 在IIS7的应用程序池有两种模式,一种是“集成模式”,一种是“经典模式”. 经典模式 则是我们以前习惯的IIS 6 的方式. 如果使用集成模式,那么对自定义的httpModules 和 httpHandlers 就要修改配置文件,需要将他们转移到<modules