Hi Jean-Philippe,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180221]
[cannot apply to iommu/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jean-Philippe-Brucker/Add-virtio-iommu-driver/20180217-075417
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
aarch64-linux-gnu-ld: arch/arm64/kernel/head.o: relocation R_AARCH64_ABS32
against `_kernel_offset_le_lo32' can not be used when making a shared object
arch/arm64/kernel/head.o: In function `kimage_vaddr':
(.idmap.text+0x0): dangerous relocation: unsupported relocation
arch/arm64/kernel/head.o: In function `__primary_switch':
(.idmap.text+0x340): dangerous relocation: unsupported relocation
(.idmap.text+0x348): dangerous relocation: unsupported relocation
drivers/iommu/virtio-iommu.o: In function `viommu_probe':
virtio-iommu.c:(.text+0xbdc): undefined reference to
`virtio_check_driver_offered_feature'
virtio-iommu.c:(.text+0xcfc): undefined reference to
`virtio_check_driver_offered_feature'
virtio-iommu.c:(.text+0xe10): undefined reference to
`virtio_check_driver_offered_feature'
drivers/iommu/virtio-iommu.o: In function `viommu_send_reqs_sync':
virtio-iommu.c:(.text+0x130c): undefined reference to `virtqueue_add_sgs'
virtio-iommu.c:(.text+0x1398): undefined reference to `virtqueue_kick'
virtio-iommu.c:(.text+0x14d4): undefined reference to `virtqueue_get_buf'
drivers/iommu/virtio-iommu.o: In function `virtio_iommu_drv_init':
virtio-iommu.c:(.init.text+0x1c): undefined reference to
`register_virtio_driver'
drivers/iommu/virtio-iommu.o: In function
`virtio_iommu_drv_exit':>> virtio-iommu.c:(.exit.text+0x14): undefined reference to
`unregister_virtio_driver'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 59126 bytes
Desc: not available
URL:
<http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20180222/d9eae8ad/attachment-0001.bin>
On 21/02/18 20:12, kbuild test robot wrote: [...]> config: arm64-allmodconfig (attached as .config)[...]> aarch64-linux-gnu-ld: arch/arm64/kernel/head.o: relocation R_AARCH64_ABS32 against `_kernel_offset_le_lo32' can not be used when making a shared object > arch/arm64/kernel/head.o: In function `kimage_vaddr': > (.idmap.text+0x0): dangerous relocation: unsupported relocationIs this related?> arch/arm64/kernel/head.o: In function `__primary_switch': > (.idmap.text+0x340): dangerous relocation: unsupported relocation > (.idmap.text+0x348): dangerous relocation: unsupported relocation > drivers/iommu/virtio-iommu.o: In function `viommu_probe': > virtio-iommu.c:(.text+0xbdc): undefined reference to `virtio_check_driver_offered_feature' > virtio-iommu.c:(.text+0xcfc): undefined reference to `virtio_check_driver_offered_feature' > virtio-iommu.c:(.text+0xe10): undefined reference to `virtio_check_driver_offered_feature' > drivers/iommu/virtio-iommu.o: In function `viommu_send_reqs_sync': > virtio-iommu.c:(.text+0x130c): undefined reference to `virtqueue_add_sgs' > virtio-iommu.c:(.text+0x1398): undefined reference to `virtqueue_kick' > virtio-iommu.c:(.text+0x14d4): undefined reference to `virtqueue_get_buf' > drivers/iommu/virtio-iommu.o: In function `virtio_iommu_drv_init': > virtio-iommu.c:(.init.text+0x1c): undefined reference to `register_virtio_driver' > drivers/iommu/virtio-iommu.o: In function `virtio_iommu_drv_exit': >>> virtio-iommu.c:(.exit.text+0x14): undefined reference to `unregister_virtio_driver'Right. At the moment CONFIG_VIRTIO_IOMMU is a bool instead of tristate, because the IOMMU subsystem isn't entirely ready to have IOMMU drivers built as modules. In addition to exporting symbols it would also needs to hold off probing endpoints behind the IOMMU until the IOMMU driver is loaded. At the moment (I think) it gives up once userspace is reached (see of_iommu_driver_present). The above report is due to VIRTIO=m and VIRTIO_IOMMU=y. To solve it we could: a) Allow VIRTIO_IOMMU to be built as module by exporting a dozen IOMMU symbols. It would be a lie. The driver wouldn't be usable because of the probe issue discussed above, but it would build. b) Actually make any IOMMU driver work as module. Whilst it would certainly be a nice feature, it's a bigger problem and I don't think it has its place in this series. c) Make VIRTIO_IOMMU depend on VIRTIO_MMIO=y instead of VIRTIO_MMIO, which I think is the sanest for now (and does work), even though distro kernels probably all have VIRTIO=m. I prefer doing c) now and experiment with b) once I got some time. Thanks, Jean
On Thu, Feb 22, 2018 at 11:04:30AM +0000, Jean-Philippe Brucker wrote:> On 21/02/18 20:12, kbuild test robot wrote: > [...] > > config: arm64-allmodconfig (attached as .config) > [...] > > aarch64-linux-gnu-ld: arch/arm64/kernel/head.o: relocation R_AARCH64_ABS32 against `_kernel_offset_le_lo32' can not be used when making a shared object > > arch/arm64/kernel/head.o: In function `kimage_vaddr': > > (.idmap.text+0x0): dangerous relocation: unsupported relocation > > Is this related? > > > arch/arm64/kernel/head.o: In function `__primary_switch': > > (.idmap.text+0x340): dangerous relocation: unsupported relocation > > (.idmap.text+0x348): dangerous relocation: unsupported relocation > > drivers/iommu/virtio-iommu.o: In function `viommu_probe': > > virtio-iommu.c:(.text+0xbdc): undefined reference to `virtio_check_driver_offered_feature' > > virtio-iommu.c:(.text+0xcfc): undefined reference to `virtio_check_driver_offered_feature' > > virtio-iommu.c:(.text+0xe10): undefined reference to `virtio_check_driver_offered_feature' > > drivers/iommu/virtio-iommu.o: In function `viommu_send_reqs_sync': > > virtio-iommu.c:(.text+0x130c): undefined reference to `virtqueue_add_sgs' > > virtio-iommu.c:(.text+0x1398): undefined reference to `virtqueue_kick' > > virtio-iommu.c:(.text+0x14d4): undefined reference to `virtqueue_get_buf' > > drivers/iommu/virtio-iommu.o: In function `virtio_iommu_drv_init': > > virtio-iommu.c:(.init.text+0x1c): undefined reference to `register_virtio_driver' > > drivers/iommu/virtio-iommu.o: In function `virtio_iommu_drv_exit': > >>> virtio-iommu.c:(.exit.text+0x14): undefined reference to `unregister_virtio_driver' > > Right. At the moment CONFIG_VIRTIO_IOMMU is a bool instead of tristate, > because the IOMMU subsystem isn't entirely ready to have IOMMU drivers > built as modules. In addition to exporting symbols it would also needs to > hold off probing endpoints behind the IOMMU until the IOMMU driver is > loaded. At the moment (I think) it gives up once userspace is reached (see > of_iommu_driver_present). > > The above report is due to VIRTIO=m and VIRTIO_IOMMU=y. To solve it we could: > > a) Allow VIRTIO_IOMMU to be built as module by exporting a dozen IOMMU > symbols. It would be a lie. The driver wouldn't be usable because of the > probe issue discussed above, but it would build. > > b) Actually make any IOMMU driver work as module. Whilst it would > certainly be a nice feature, it's a bigger problem and I don't think it > has its place in this series. > > c) Make VIRTIO_IOMMU depend on VIRTIO_MMIO=y instead of VIRTIO_MMIO, which > I think is the sanest for now (and does work), even though distro kernels > probably all have VIRTIO=m. > > I prefer doing c) now and experiment with b) once I got some time. > > Thanks, > JeanIt kind of means it's a toy for now though. So fine as long as it's out of tree. -- MST