iommu分析之---intel iommu初始化
intel 的iommu 是iommu框架的一个实现案例。
由于intel 的iommu 实现得比arm smmv3复杂得多,里面概念也多,所以针对intel 实现的iommu 案例的初始化部分进行一些讲解,本文针对4.19内核。
Intel IOMMU的初始化函数在哪调用的呢?
它的初始化函数是:
int __init intel_iommu_init(void)
{
int ret = -ENODEV;
struct dmar_drhd_unit *drhd;
struct intel_iommu *iommu;
/* VT-d is required for a TXT/tboot launch, so enforce that */
force_on = tboot_force_iommu();
那这个函数是在常见的模块初始化里面调用的么?
事实上,它的调用链是这样的,
int __init detect_intel_iommu(void)//caq:IOMMU_INIT_POST调用这个,有amd的,ibm大型机的
{//caq:此时还没有memory allocator
int ret;
struct dmar_res_callback validate_drhd_cb = {
.cb[ACPI_DMAR_TYPE_HARDWARE_UNIT] = &dmar_validate_one_drhd,
.ignore_unhandled = true,
};
down_write(&dmar_global_lock);
ret = dmar_table_detect();//caq:bios/uefi提供的dmar table
if (!ret)
ret = dmar_walk_dmar_table((struct acpi_table_dmar *)dmar_tbl,
&validate_drhd_cb);
if (!ret && !no_iommu && !iommu_detected && !dmar_disabled) {
iommu_detected = 1;//caq:返回正常就设定这个标志位
/* Make sure ACS will be enabled */
pci_request_acs();
}
#ifdef CONFIG_X86
if (!ret)
**x86_init.iommu.iommu_init = intel_iommu_init;//caq:pci_iommu_init 会统一执行iommu_init**
#endif
if (dmar_tbl) {
acpi_put_table(dmar_tbl);//caq:释放资源
dmar_tbl = NULL;
}
up_write(&dmar_global_lock);
return ret ? ret : 1;
}
在 detect_intel_iommu 函数中,有一个关键行:
x86_init.iommu.iommu_init = intel_iommu_init;//caq:pci_iommu_init 会统一执行iommu_init
然后在 pci_iommu_init 会统一执行 iommu_init 。如下:
static int __init pci_iommu_init(void)
{
struct iommu_table_entry *p;
**x86_init.iommu.iommu_init();//caq:执行前面 detect_intel_iommu 里面对 x86_init.iommu 赋值的指针。**
for (p = __iommu_table; p < __iommu_table_end; p++) {
if (p && (p->flags & IOMMU_DETECTED) && p->late_init)
p->late_init();
}
return 0;
}
如下的调用链:
kernel_init ->
kernel_init_freeable ->
do_one_initcall ->
pci_iommu_init ->
x86_init.iommu.iommu_init
以上就是intel 的iommu 初始化调用链分析。
常见问题:
1、intel怎么管理那么多iommu硬件?
使用一个全局的 dmar_drhd_units 链表来管理对应的iommu硬件,dmar_drhd_unit 的list 成员串接在这个全局链表中。
crash> list -H dmar_drhd_units -s dmar_drhd_unit.segment,devices_cnt
ffff8b83ff078780
segment = 0
devices_cnt = 0
ffff8b83ff078060
segment = 0
devices_cnt = 0
ffff8b83ff065680---------管理了三个设备
segment = 0
devices_cnt = 3
ffff8b83ff078ae0
segment = 0
devices_cnt = 0
ffff8b83ff078c60
segment = 0
devices_cnt = 0
ffff8b83ff078480
segment = 0
devices_cnt = 0
ffff8b83ff072180--------------管理了8个设备
segment = 0
devices_cnt = 8
ffff8b83ff078240
segment = 0
devices_cnt = 0
我们可以看到,bios/uefi至少枚举了8个iommu的硬件,其中两个intel_iommu设备 分别管理的3个和8个设备。
2、是不是devices_cnt就是所有的设备呢?
实际单板上,pci设备就远远不止11个设备,那么其他设备怎么办呢?devices_cnt 为0,不代表它就不管理设备,相反,还得继续看include_all标志,
事实上,这个在如下函数有体现:
struct dmar_drhd_unit *
dmar_find_matched_drhd_unit(struct pci_dev *dev)//caq:pci设备找归属的drhd_unit 硬件
{
struct dmar_drhd_unit *dmaru;
struct acpi_dmar_hardware_unit *drhd;
dev = pci_physfn(dev);
rcu_read_lock();
for_each_drhd_unit(dmaru) {
drhd = container_of(dmaru->hdr,
struct acpi_dmar_hardware_unit,
header);
if (dmaru->**include_all **&&
drhd->segment == pci_domain_nr(dev->bus))//caq:include_all是segment内的,不是整个系统的
goto out;
if (dmar_pci_device_match(dmaru->devices,//caq:在对应的unit 的devices 数组中找到了dev
dmaru->devices_cnt, dev))
goto out;
}
dmaru = NULL;//caq:否则返回NULL
out:
rcu_read_unlock();
return dmaru;
}
也就是说,通过一个dmar硬件,支持include_all属性,将很多设备收纳了其中,比如看的其他一个服务器的打印:
crash> dmar_drhd_unit.iommu,include_all,devices_cnt ffff8d1240078360
iommu = 0xffff8d42ff043500
include_all = 1 '\001'
devices_cnt = 0
crash> intel_iommu.name 0xffff8d42ff043500
name = "dmar7\000\000\000\000\000\000\000"
上面可以看到,dmar7的 devices_cnt 为0,但是真实的管理设备个数却很多,如下:
[root@localhost devices]# pwd
/sys/class/iommu/dmar7/devices
[root@localhost devices]# ll |wc -l
281
3、如何查看一个设备归属的iommu?
除此之外,真正让一个device跟iommu关联的函数,其实可以查看:
//caq:bus和devfn是出参
static struct intel_iommu *device_to_iommu(struct device *dev, u8 *bus, u8 *devfn)
{
struct dmar_drhd_unit *drhd = NULL;
struct intel_iommu *iommu;
struct device *tmp;
struct pci_dev *ptmp, *pdev = NULL;
u16 segment = 0;
int i;
if (iommu_dummy(dev))//caq:该设备没有关联归属iommu,
return NULL;
if (dev_is_pci(dev)) {//caq:pci设备,也就是他的bus type 是pci_bus_type
struct pci_dev *pf_pdev;
pdev = to_pci_dev(dev);
#ifdef CONFIG_X86
/* VMD child devices currently cannot be handled individually */
if (is_vmd(pdev->bus))//caq:VMD:Intel Volume Management Device
return NULL;
#endif
/* VFs aren't listed in scope tables; we need to look up
* the PF instead to find the IOMMU. */
pf_pdev = pci_physfn(pdev);//caq:以 pf 为dev,在drhd管理的dev中,是看不到vf的
dev = &pf_pdev->dev;
segment = pci_domain_nr(pdev->bus);//caq:segment其实就是bus归属的domain
} else if (has_acpi_companion(dev))
dev = &ACPI_COMPANION(dev)->dev;
rcu_read_lock();
for_each_active_iommu(iommu, drhd) {//caq:除掉ignored 的所有 intel_iommu
if (pdev && segment != drhd->segment)
continue;
for_each_active_dev_scope(drhd->devices,
drhd->devices_cnt, i, tmp) {
if (tmp == dev) {
/* For a VF use its original BDF# not that of the PF
* which we used for the IOMMU lookup. Strictly speaking
* we could do this for all PCI devices; we only need to
* get the BDF# from the scope table for ACPI matches. */
if (pdev && pdev->is_virtfn)//caq:如果是vf 设备,则 拿 pf
goto got_pdev;
*bus = drhd->devices[i].bus;//caq:取bus 号
*devfn = drhd->devices[i].devfn;//caq:取 device和func 号
goto out;
}
........
ptmp = to_pci_dev(tmp);
if (ptmp->subordinate &&//caq:范围查找
ptmp->subordinate->number <= pdev->bus->number &&
ptmp->subordinate->busn_res.end >= pdev->bus->number)
goto got_pdev;
}
if (pdev && drhd->include_all) {
got_pdev:
*bus = pdev->bus->number;
*devfn = pdev->devfn;
goto out;
}
}
iommu = NULL;
out:
rcu_read_unlock();
return iommu;
}
从如上函数可以看出,跟iommu关联的设备数,可能会远远大于在drhd中看到的devices_cnt,事实上,这个devices_cnt很容易让人误解。
4、dmar_disabled 的意思?
但是需要注意的是,如果intel_iommu=on 没有设置,且 CONFIG_INTEL_IOMMU_DEFAULT_ON 这个config没有开启,则会导致 dmar_disabled 为1.
#ifdef CONFIG_INTEL_IOMMU_DEFAULT_ON
int dmar_disabled = 0;//caq:默认是否开启取决于 CONFIG_INTEL_IOMMU_DEFAULT_ON 是否配置
#else
int dmar_disabled = 1;
#endif /*CONFIG_INTEL_IOMMU_DEFAULT_ON*/
这个 dmar_disabled 的值会影响 int __init intel_iommu_init(void) 函数的行为,
int __init intel_iommu_init(void)
{
.....
if (no_iommu || dmar_disabled) {//caq:
/*
* We exit the function here to ensure IOMMU's remapping and
* mempool aren't setup, which means that the IOMMU's PMRs
* won't be disabled via the call to init_dmars(). So disable
* it explicitly here. The PMRs were setup by tboot prior to
* calling SENTER, but the kernel is expected to reset/tear
* down the PMRs.
*/
if (intel_iommu_tboot_noforce) {
for_each_iommu(iommu, drhd)
iommu_disable_protect_mem_regions(iommu);
}
/*
* Make sure the IOMMUs are switched off, even when we
* boot into a kexec kernel and the previous kernel left
* them enabled
*/
intel_disable_iommus();//caq:导致intel_iommu的功能被关闭,也就是调用 iommu_disable_translation
goto out_free_dmar;
}
.....
所以我们经常能看到硬件上是有很多drhd的硬件,但是软件上并没有使能,当然也就没有注册到 iommu框架中的,iommu_device_register不会被调用,
全局的 iommu_device_list 只是空的,留下寂寞空虚冷。
而如果软件上使能了的话,iommu_device_list 就会保留有当前期active的 iommu device,如下:
crash> list -H iommu_device_list -s iommu_device.ops-----------//caq:注意,这个链表只有active的成员。
ffff9994ff0709c8
ops = 0xffffffff952ebcc0
ffff99a53f043dc8
ops = 0xffffffff952ebcc0
crash> dis -l 0xffffffff952ebcc0
0xffffffff952ebcc0 <intel_iommu_ops>: adcb $0xff,-0x6b72(%rdi)
非active的iommu,不会展示在sysfs中,如下案例:
具备iommu功能的硬件打印:
crash> list -H dmar_drhd_units -s dmar_drhd_unit.segment,devices_cnt,include_all,ignored
ffff8d1240078e40
segment = 0
devices_cnt = 0
include_all = 0 '\000'
ignored = 1 '\001'
ffff8d1240078240
segment = 0
devices_cnt = 1
include_all = 0 '\000'
ignored = 0 '\000'
ffff8d1240065000
segment = 0
devices_cnt = 3
include_all = 0 '\000'
ignored = 0 '\000'
ffff8d1240078780
segment = 0
devices_cnt = 0
include_all = 0 '\000'
ignored = 1 '\001'
ffff8d12400783c0
segment = 0
devices_cnt = 0
include_all = 0 '\000'
ignored = 1 '\001'
ffff8d1240078960
segment = 0
devices_cnt = 0
include_all = 0 '\000'
ignored = 1 '\001'
ffff8d1240072fc0
segment = 0
devices_cnt = 8
include_all = 0 '\000'
**ignored = 1** '\001'//caq:虽然 devices_cnt 不为0,但是依然被ignored。
ffff8d1240078360
segment = 0
devices_cnt = 0
include_all = 1 '\001'
ignored = 0 '\000'
除掉这些ignored为1的,可以看到active的iommu设备,
angus@jm212:/sys/class/iommu$ pwd
/sys/class/iommu
angus@jm212:/sys/class/iommu$ ls
dmar4 dmar5 dmar7
iommu分析之---intel iommu初始化的更多相关文章
- iommu分析之---intel irq remap框架实现
背景介绍: IRQ域层级结构: 在某些架构上,可能有多个中断控制器参与将一个中断从设备传送到目标CPU. 让我们来看看x86平台上典型的中断传递路径吧 Device --> IOAPIC -&g ...
- 《深入理解Spark:核心思想与源码分析》——SparkContext的初始化(叔篇)——TaskScheduler的启动
<深入理解Spark:核心思想与源码分析>一书前言的内容请看链接<深入理解SPARK:核心思想与源码分析>一书正式出版上市 <深入理解Spark:核心思想与源码分析> ...
- 【spring源码分析】IOC容器初始化(总结)
前言:在经过前面十二篇文章的分析,对bean的加载流程大致梳理清楚了.因为内容过多,因此需要进行一个小总结. 经过前面十二篇文章的漫长分析,终于将xml配置文件中的bean,转换成我们实际所需要的真正 ...
- 【spring源码分析】IOC容器初始化(二)
前言:在[spring源码分析]IOC容器初始化(一)文末中已经提出loadBeanDefinitions(DefaultListableBeanFactory)的重要性,本文将以此为切入点继续分析. ...
- 【spring源码分析】IOC容器初始化(三)
前言:在[spring源码分析]IOC容器初始化(二)中已经得到了XML配置文件的Document实例,下面分析bean的注册过程. XmlBeanDefinitionReader#registerB ...
- 【spring源码分析】IOC容器初始化(四)
前言:在[spring源码分析]IOC容器初始化(三)中已经分析了BeanDefinition注册之前的一些准备工作,下面将进入BeanDefinition注册的核心流程. //DefaultBean ...
- 【spring源码分析】IOC容器初始化(五)
前言:前几篇文章已经将BeanDefinition的加载过程大致分析完成,接下来继续分析其他过程. AbstractApplicationContext#refresh public void ref ...
- 【spring源码分析】IOC容器初始化(七)
前言:在[spring源码分析]IOC容器初始化(六)中分析了从单例缓存中加载bean对象,由于篇幅原因其核心函数 FactoryBeanRegistrySupport#getObjectFromFa ...
- 【spring源码分析】IOC容器初始化(九)
前言:上篇文章末尾提到createBeanInstance方法中使用工厂方法实例化Bean对象,本文将对该方法进行分析. AbstractAutowireCapableBeanFactory#inst ...
随机推荐
- html5手册语义化标签
html5手册语义化标签: article section aside hgroup header footer nav time mark figure figcaption contextmenu ...
- 钉钉登录二维码嵌套在vue页面中
转自 https://www.csdn.net/tags/OtDacg3sMjQ2NTgtYmxvZwO0O0OO0O0O.html 钉钉登录二维码嵌套在vue页面中 2021-09-04 14:42 ...
- Docker搭建大数据集群 Hadoop Spark HBase Hive Zookeeper Scala
Docker搭建大数据集群 给出一个完全分布式hadoop+spark集群搭建完整文档,从环境准备(包括机器名,ip映射步骤,ssh免密,Java等)开始,包括zookeeper,hadoop,hiv ...
- 基于“均态分布”随机数算法的一次性口令OneTimePassword(原创)
/* 所谓均态分布随机数算法是指:每个数(整数或实数)无序地分布在数轴上,值只出现一次永不重复.体现了香农的一次一密理论. * 均体现在每个数的值是平均概率,即都有出现:态体现在每个数在数轴上的位置是 ...
- [自制操作系统] 第04回 完善MBR
目录 一.前景回顾 二.改写MBR 三.实现loader 一.前景回顾 在之前我们说到,MBR的作用便是加载操作系统内核到指定位置.而MBR需要通过读取硬盘来获得操作系统内核.在上一回我们已经讲解了硬 ...
- Java实用类-Enum(枚举)
1. 历史 在 JDK 1.5 之前没有枚举类型,那时候一般用接口常量来替代(例如,public static final String male ).JKD1.5之后使用 Java 枚举类型 e ...
- 16.Nginx优化与防盗链
Nginx优化与防盗链 目录 Nginx优化与防盗链 隐藏版本号 修改用户与组 缓存时间 日志切割 小知识 连接超时 更改进程数 配置网页压缩 配置防盗链 配置防盗链 隐藏版本号 可以使用 Fiddl ...
- 怎么理解相互独立事件?真的是没有任何关系的事件吗?《考研概率论学习之我见》 -by zobol
1.从条件概率的定义来看独立事件的定义 2.从古典概率的定义来看独立事件的定义 3.P(A|B)和P(A)的关系是什么? 4.由P(AB)=P(A)P(B)推出"独立" 5.从韦恩 ...
- Xshell缺失mfc110u.dll文件解决方案(有下载链接)
解决方案 把下面两个文件都下载安装就可以了. 1.vcredist_x86.exe链接: https://pan.baidu.com/s/1njbNHdjqH6x34GQvj4BTBg提取码: pwq ...
- nifi从入门到实战(保姆级教程)——环境篇
背景: 公司领导决定将各种基础数据的导入从代码中分离出来,用Apache Nifi替换.使开发者们更关注在业务上,而不用关心基础的由来. Apache Nifi对于整个团队都是一个全新的工具,之前大家 ...