From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux-foundation.org,
virtualization@lists.linux-foundation.org,
linux-pci@vger.kernel.org, virtio-dev@lists.oasis-open.org,
rjw@rjwysocki.net, lenb@kernel.org, lorenzo.pieralisi@arm.com,
guohanjun@huawei.com, sudeep.holla@arm.com,
gregkh@linuxfoundation.org, joro@8bytes.org, bhelgaas@google.com,
jasowang@redhat.com, jacob.jun.pan@intel.com,
eric.auger@redhat.com, sebastien.boeuf@intel.com,
kevin.tian@intel.com
Subject: Re: [RFC 00/13] virtio-iommu on non-devicetree platforms
Date: Mon, 25 Nov 2019 18:53:16 +0100 [thread overview]
Message-ID: <20191125175316.GC945122@lophozonia> (raw)
In-Reply-To: <20191122075438-mutt-send-email-mst@kernel.org>
On Fri, Nov 22, 2019 at 08:00:46AM -0500, Michael S. Tsirkin wrote:
> > (2) In addition, there are some concerns about having virtio depend on
> > ACPI or DT. Some hypervisors (Firecracker, QEMU microvm, kvmtool x86
> > [1])
>
> power?
In kvmtool it boot with device tree. It also doesn't need virtio-iommu I
think, since it has its own paravirtualized interface.
> > don't currently implement those methods.
> >
> > It was suggested to embed the topology description into the device.
> > It can work, as demonstrated at the end of this RFC, with the
> > following limitations:
> >
> > - The topology description must be read before any endpoint managed
> > by the IOMMU is probed, and even before the virtio module is
> > loaded. This RFC uses a PCI quirk to manually parse the virtio
> > configuration. It assumes that all endpoints managed by the IOMMU
> > are under this same PCI host.
> >
> > - I don't have a solution for the virtio-mmio transport at the
> > moment, because I haven't had time to modify a host to test it. I
> > think it could either use a notifier on the platform bus, or
> > better, a new 'iommu' command-line argument to the virtio-mmio
> > driver.
>
> A notifier seems easier for users. What are the disadvantages of
> that?
For each device we have to check if it's virtio-mmio, then map the MMIO
resource and check the device type. Having a dedicated command-line
argument would be more efficient.
Thanks,
Jean
next prev parent reply other threads:[~2019-11-25 17:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-22 10:49 [RFC 00/13] virtio-iommu on non-devicetree platforms Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 01/13] ACPI/IORT: Move IORT to the ACPI folder Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 02/13] ACPI: Add VIOT definitions Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 03/13] ACPI/IORT: Allow registration of external tables Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 04/13] ACPI/IORT: Add node categories Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 05/13] ACPI/IORT: Support VIOT virtio-mmio node Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 06/13] ACPI/IORT: Support VIOT virtio-pci node Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 07/13] ACPI/IORT: Defer probe until virtio-iommu-pci has registered a fwnode Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 08/13] ACPI/IORT: Add callback to update a device's fwnode Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 09/13] iommu/virtio: Create fwnode if necessary Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 10/13] iommu/virtio: Update IORT fwnode Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 11/13] ACPI: Add VIOT table Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC virtio 12/13] virtio-iommu: Add built-in topology description Jean-Philippe Brucker
2019-11-22 10:50 ` [RFC 13/13] iommu/virtio: Add topology description to Jean-Philippe Brucker
2019-11-22 12:53 ` Michael S. Tsirkin
2019-11-25 17:48 ` Jean-Philippe Brucker
2019-11-22 13:00 ` [RFC 00/13] virtio-iommu on non-devicetree platforms Michael S. Tsirkin
2019-11-25 17:53 ` Jean-Philippe Brucker [this message]
2019-11-23 0:01 ` Jacob Pan (Jun)
2019-11-25 18:02 ` Jean-Philippe Brucker
2019-12-04 3:01 ` Jacob Pan (Jun)
2019-12-18 11:20 ` Jean-Philippe Brucker
2019-12-20 18:54 ` Jacob Pan (Jun)
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=20191125175316.GC945122@lophozonia \
--to=jean-philippe@linaro.org \
--cc=bhelgaas@google.com \
--cc=eric.auger@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=guohanjun@huawei.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--cc=jasowang@redhat.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mst@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=sebastien.boeuf@intel.com \
--cc=sudeep.holla@arm.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;
as well as URLs for NNTP newsgroup(s).