Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Cc: kbuild test robot <lkp@intel.com>,
	"kbuild-all@01.org" <kbuild-all@01.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	Robin Murphy <Robin.Murphy@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"eric.auger.pro@gmail.com" <eric.auger.pro@gmail.com>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"bharat.bhushan@nxp.com" <bharat.bhushan@nxp.com>,
	"tnowicki@caviumnetworks.com" <tnowicki@caviumnetworks.com>,
	"jayachandran.nair@cavium.com" <jayachandran.nair@cavium.com>,
	"kevin.tian@intel.com" <kevin.tian@intel.com>,
	"jintack@cs.columbia.edu" <jintack@cs.columbia.edu>
Subject: [virtio-dev] Re: [PATCH 1/4] iommu: Add virtio-iommu driver
Date: Tue, 27 Feb 2018 16:47:22 +0200	[thread overview]
Message-ID: <20180227164510-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <e5ffc52f-4510-f757-aa83-2a99af3ae06b@arm.com>

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,
> Jean

It kind of means it's a toy for now though. So fine as long
as it's out of tree.

-- 
MST

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2018-02-27 14:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-14 14:53 [virtio-dev] [PATCH 0/4] Add virtio-iommu driver Jean-Philippe Brucker
2018-02-14 14:53 ` [virtio-dev] [PATCH 1/4] iommu: " Jean-Philippe Brucker
     [not found]   ` <417e1617-e5ff-7b13-64e3-a8a98d30bcb9@semihalf.com>
2018-02-20 11:30     ` [virtio-dev] " Jean-Philippe Brucker
     [not found]   ` <201802220455.lMEb6LLi%fengguang.wu@intel.com>
2018-02-22 11:04     ` Jean-Philippe Brucker
2018-02-27 14:47       ` Michael S. Tsirkin [this message]
2018-03-21  6:43   ` [virtio-dev] " Tian, Kevin
2018-03-21 13:14     ` [virtio-dev] " Jean-Philippe Brucker
     [not found]       ` <739fbfdf-1651-8036-367a-52940b93dee6@arm.com>
2018-03-22 10:06         ` [virtio-dev] " Tian, Kevin
     [not found]         ` <AADFC41AFE54684AB9EE6CBC0274A5D19108DC42@SHSMSX101.ccr.corp.intel.com>
2018-03-23  8:27           ` Tian, Kevin
2018-04-11 18:35             ` [virtio-dev] " Jean-Philippe Brucker
     [not found]   ` <d0cfe602-f6e8-2d6e-0942-23012f3facef@arm.com>
2018-04-11 18:33     ` Jean-Philippe Brucker
2018-02-14 14:53 ` [virtio-dev] [PATCH 2/4] iommu/virtio: Add probe request Jean-Philippe Brucker
     [not found]   ` <8156517f-74b1-2923-2838-402f09a5c488@arm.com>
2018-04-11 18:33     ` [virtio-dev] " Jean-Philippe Brucker
2018-02-14 14:53 ` [virtio-dev] [PATCH 3/4] iommu/virtio: Add event queue Jean-Philippe Brucker
2018-02-14 14:53 ` [virtio-dev] [PATCH 4/4] vfio: Allow type-1 IOMMU instantiation with a virtio-iommu Jean-Philippe Brucker
     [not found]   ` <20180214082639.54556efb@w520.home>
     [not found]     ` <9f98aa85-3160-e285-cacd-2f429c58a775@arm.com>
2018-02-15 13:53       ` [virtio-dev] " Jean-Philippe Brucker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180227164510-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=Robin.Murphy@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=alex.williamson@redhat.com \
    --cc=bharat.bhushan@nxp.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jasowang@redhat.com \
    --cc=jayachandran.nair@cavium.com \
    --cc=jean-philippe.brucker@arm.com \
    --cc=jintack@cs.columbia.edu \
    --cc=joro@8bytes.org \
    --cc=kbuild-all@01.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=lkp@intel.com \
    --cc=peterx@redhat.com \
    --cc=tnowicki@caviumnetworks.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox