PCI规范里BAR寄存器的一段话看不懂

Solaris12

原帖由 Cyberman.Wu 于 2009-3-20 12:47 发表


在最前面全部是连续1的时候的两种算法得到的结果是相同的，我也见过有资料按你说的办法去判断空间大小的，Linux的具体实现没看过，在PC上BIOS本身也会做这件事吧。
如你所说是可以灵活一些，但实际上PCI规 ...

你说的我都知道，我说的是为什么很多OS都没有照规范的建议去做，除了我的分析，还有没有其它原因呢？

这个恐怕只有写那行 code的人才知道了。


另外，我的新问题是，在Xen里DomU里的Linux要不要对BAR来重新设置？

Cyberman.Wu

原帖由 Solaris12 于 2009-3-20 13:04 发表



你说的我都知道，我说的是为什么很多OS都没有照规范的建议去做，除了我的分析，还有没有其它原因呢？

这个恐怕只有写那行 code的人才知道了。


另外，我的新问题是，在Xen里DomU里的Linux要不要对 ...

有没有原因就不知道了，呵呵，OS有些代码如果没有原设计者的解释别人很难弄清楚了，它里面的resource数组还是12个元素的，但sysfs导出来的是前7个，6个BAR加一个ROM的，其余的用来干啥也没搞清楚。

Xen没研究过，不清楚。

Solaris12

原帖由 Cyberman.Wu 于 2009-3-22 13:24 发表



有没有原因就不知道了，呵呵，OS有些代码如果没有原设计者的解释别人很难弄清楚了，它里面的resource数组还是12个元素的，但sysfs导出来的是前7个，6个BAR加一个ROM的，其余的用来干啥也没搞清楚。

Xe ...

最近我在Solaris的Dom0里实现了一段对6个BAR和ROM的size probe做模拟的代码, 在Solaris DomU里可以工作，但对Linux DomU实在是没有把握，看来得自己研究了。

epegasus

<pci体系结构>这本书里讲的很清楚了.
第一次写进去的全一,读出来为非1,那么高几位连续的1就是可编程的,首先他代表了映射区域的最小"分片",这个写的过程其实也是在编程BAR,既是说已经把设备内存做了一次映射,而且是映射到最大的可能地址.从而这个写-读的过程是不应该出现在系统后期的,否则他改变了系统的总线地址(或物理地址),很容易发生地址冲突.
知道几个为1的位后就可以对它编程写入其他值,这些值就是从新设置新的起始地址,由于其他位不可编程,当然起始地址就是个离散值.
那些为0的位实际上是硬件电路接发直接定死的.
为什么是2G呢?所有的设备是都用同一4G的存储空间,那么最大就是2G一个段了,因为如果是4G的话,就没必要用PCI总线了,一个设备已经独占了4G.
从而linux代码对总线的操作和PCI BIOS没有本质不同.

原帖由 Solaris12 于 2009-3-17 00:06 发表


OpenSolaris的add_reg_props的代码就是这么做的。

OpenSolaris的add_reg_props函数里，首先是将BAR读出备份，然后写全1，然后读，结果存在value里，再将备份BAR写回，

                /* determine  ...

通常是是物理地址,我想如果动态的改BAR也可以,不过之前做的很多工作要从新做.
最起码的是在重新探测的过程不能执行存储器和IO的交易.

不过不明白你说的机器地址是什么意思.

[ 本帖最后由 epegasus 于 2009-4-13 12:50 编辑 ]

Solaris12

原帖由 epegasus 于 2009-4-13 11:01 发表
<pci体系结构>这本书里讲的很清楚了.
第一次写进去的全一,读出来为非1,那么高几位连续的1就是可编程的,首先他代表了映射区域的最小"分片",这个写的过程其实也是在编程BAR,既是说已经把设备内存做了一次映射,而且是映射到最大的可能地址.从而这个写-读的过程是不应该出现在系统后期的,否则他改变了系统的总线地址(或物理地址),很容易发生地址冲突.
................snip...................
通常是是物理地址,我想如果动态的改BAR也可以,不过之前做的很多工作要从新做.
最起码的是在重新探测的过程不能执行存储器和IO的交易.

不过不明白你说的机器地址是什么意思. ...

是啊，你就是没明白我的问题

我的问题是当分配一个真实的物理设备给Para Virtualaization的DomU，这时Linux在DomU里是否还需要对BAR重新编程，如果是，写入的地址是机器地址还是物理地址？

其实如果是Full Virtualaization的DomU的话，<系统虚拟化原理与实现>第148和149页已经有描述了，我就不多说了。

但如果是Para Vitualaization，我现在猜想，Linux的代码可能被改过了，因为pv方式应该是通过hypercall主动陷入到VMM里，而DomU对BAR的修改会引起系统资源冲突，所以我相信这里Linux在DomU的代码应该是直接读Dom0里分配的BAR就可以了，没必要去修改它。

至于机器地址和物理地址和虚拟地址的差别，<系统虚拟化原理与实现>有介绍。

因为工作原因没办法看Linux代码，谁可以看下Xen Linux 的代码确认一下这个问题，那是最好的了。不过我觉得我的想法应该是正确的。

epegasus

如果"机器地址"是指虚拟机的物理地址的话,
如果是iommu的情况下,按道理应该是"机器地址",因为DMA被写入的是"机器地址",那么设备肯定会拿这个地址做总线的寻址,那么可能需要从新分配PCI设备地址空间了,也就是重新写BAR.那地址管理是个问题.
书上第5章提到的2种方式,直接通报个客户机的话,就不用重新分配了.

顺便问个新的菜问题.
书上很多讲的都是设备直接分配给虚拟机.我好象看见别人win下装的虚拟机可能多个客户机和真实机能共用同一个网卡.在没有IOMMU的时候,我猜想可能是真实机将网卡设为混杂模式,然后根据MAC地址传递不同的虚拟机的网卡.
那么在IOMMU的时候,是不是客户机独占了网卡设备?

[ 本帖最后由 epegasus 于 2009-4-14 09:20 编辑 ]

Solaris12

原帖由 epegasus 于 2009-4-14 09:14 发表
如果"机器地址"是指虚拟机的物理地址的话,
如果是iommu的情况下,按道理应该是"机器地址",因为DMA被写入的是"机器地址",那么设备肯定会拿这个地址做总线的寻址,那么可能需要从新分配PCI设备地址空间了,也就是重新写BAR.那地址管理是个问题.
书上第5章提到的2种方式,直接通报个客户机的话,就不用重新分配了.

顺便问个新的菜问题.
书上很多讲的都是设备直接分配给虚拟机.我好象看见别人win下装的虚拟机可能多个客户机和真实机能共用同一个网卡.在没有IOMMU的时候,我猜想可能是真实机将网卡设为混杂模式,然后根据MAC地址传递不同的虚拟机的网卡.
那么在IOMMU的时候,是不是客户机独占了网卡设备? ...

关于第一个问题，PV方式和HVM方式是不同的，书上讲的是HVm方式，主要是实现类似影子寄存器的方式，你还是看书吧，书上讲得很清楚，机器地址是xen的叫法，书上大部分地方叫 HPA - host physical address.

对于不是direct IO的方式，就是多个客户机共享网卡在一般都实现为vnic -virtual nic

这里面分两种情况，

1, 如果不支持类似VMDq的多队列技术，那就是混杂模式

2. 如果支持类似VMDq的技术，就可以在网卡划分多个分区给不同的vnic使用，我的blog上有个文档。
最近Intel IDF上把SR-IOV和VMDq统称VT-c技术。但VMDq和SR-iov是不同的。