From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "mst@redhat.com" <mst@redhat.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"Boeuf, Sebastien" <sebastien.boeuf@intel.com>,
"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>
Subject: Re: [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space
Date: Wed, 11 Mar 2020 18:48:22 +0100 [thread overview]
Message-ID: <20200311174822.GA96893@myrica> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D19D7BE404@SHSMSX104.ccr.corp.intel.com>
On Thu, Mar 05, 2020 at 08:07:32AM +0000, Tian, Kevin wrote:
> > From: Jean-Philippe Brucker
> > Sent: Saturday, February 29, 2020 1:26 AM
> >
> > Platforms without device-tree do not currently have a method for
> > describing the vIOMMU topology. Provide a topology description embedded
> > into the virtio device.
> >
> > Use PCI FIXUP to probe the config space early, because we need to
> > discover the topology before any DMA configuration takes place, and the
> > virtio driver may be loaded much later. Since we discover the topology
> > description when probing the PCI hierarchy, the virtual IOMMU cannot
> > manage other platform devices discovered earlier.
> >
> > This solution isn't elegant nor foolproof, but is the best we can do at
>
> can you elaborate "isn't elegant nor foolproof" part? is there any other
> limitation (beside pci fixup) along the route, when comparing it to
> the ACPI-approach?
Yes "not elegant" in part because of the PCI fixup. Fixups are used to
work around bugs, and it seems strange to have one for a normal use-case.
We also have to copy some of the virtio infrastructure since this code
runs before module load. And we have to add a third DMA configuration
method.
I don't believe anymore that the "not foolproof" part is right. After
studying the device infrastructure a little more this solution seems less
fragile than I previously thought, but it's still a big hack, and it's
only half of the story.
This patch only handles PCI-based endpoints and viommu. On ACPI platforms,
where the virtio-mmio device is specified by an object with _HID LNRO0005,
supporting virtio-iommu on MMIO requires installing a bus notifier. There
I'd rather use an ACPI table for the topology. Platforms that don't have
ACPI such as microvm specify virtio-mmio devices on the command-line.
There devices are only created when the virtio-mmio module is loaded,
which is too late. In that case I think we need to add an early pass on
the command-line, instead of a bus notifier.
Thanks,
Jean
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"mst@redhat.com" <mst@redhat.com>,
"Boeuf, Sebastien" <sebastien.boeuf@intel.com>,
"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"jasowang@redhat.com" <jasowang@redhat.com>
Subject: Re: [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space
Date: Wed, 11 Mar 2020 18:48:22 +0100 [thread overview]
Message-ID: <20200311174822.GA96893@myrica> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D19D7BE404@SHSMSX104.ccr.corp.intel.com>
On Thu, Mar 05, 2020 at 08:07:32AM +0000, Tian, Kevin wrote:
> > From: Jean-Philippe Brucker
> > Sent: Saturday, February 29, 2020 1:26 AM
> >
> > Platforms without device-tree do not currently have a method for
> > describing the vIOMMU topology. Provide a topology description embedded
> > into the virtio device.
> >
> > Use PCI FIXUP to probe the config space early, because we need to
> > discover the topology before any DMA configuration takes place, and the
> > virtio driver may be loaded much later. Since we discover the topology
> > description when probing the PCI hierarchy, the virtual IOMMU cannot
> > manage other platform devices discovered earlier.
> >
> > This solution isn't elegant nor foolproof, but is the best we can do at
>
> can you elaborate "isn't elegant nor foolproof" part? is there any other
> limitation (beside pci fixup) along the route, when comparing it to
> the ACPI-approach?
Yes "not elegant" in part because of the PCI fixup. Fixups are used to
work around bugs, and it seems strange to have one for a normal use-case.
We also have to copy some of the virtio infrastructure since this code
runs before module load. And we have to add a third DMA configuration
method.
I don't believe anymore that the "not foolproof" part is right. After
studying the device infrastructure a little more this solution seems less
fragile than I previously thought, but it's still a big hack, and it's
only half of the story.
This patch only handles PCI-based endpoints and viommu. On ACPI platforms,
where the virtio-mmio device is specified by an object with _HID LNRO0005,
supporting virtio-iommu on MMIO requires installing a bus notifier. There
I'd rather use an ACPI table for the topology. Platforms that don't have
ACPI such as microvm specify virtio-mmio devices on the command-line.
There devices are only created when the virtio-mmio module is loaded,
which is too late. In that case I think we need to add an early pass on
the command-line, instead of a bus notifier.
Thanks,
Jean
next prev parent reply other threads:[~2020-03-11 17:48 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-28 17:25 [PATCH v2 0/3] virtio-iommu on x86 and non-devicetree platforms Jean-Philippe Brucker
2020-02-28 17:25 ` Jean-Philippe Brucker
2020-02-28 17:25 ` [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space Jean-Philippe Brucker
2020-02-28 17:25 ` Jean-Philippe Brucker
2020-03-01 11:17 ` Michael S. Tsirkin
2020-03-01 11:17 ` Michael S. Tsirkin
2020-03-02 16:16 ` Joerg Roedel
2020-03-02 16:16 ` Joerg Roedel
2020-03-03 10:19 ` Auger Eric
2020-03-03 10:19 ` Auger Eric
2020-03-03 13:01 ` Joerg Roedel
2020-03-03 13:01 ` Joerg Roedel
2020-03-03 14:00 ` Michael S. Tsirkin
2020-03-03 14:00 ` Michael S. Tsirkin
2020-03-03 15:53 ` Joerg Roedel
2020-03-03 15:53 ` Joerg Roedel
2020-03-03 16:09 ` Michael S. Tsirkin
2020-03-03 16:09 ` Michael S. Tsirkin
2020-03-03 16:21 ` Auger Eric
2020-03-03 16:21 ` Auger Eric
2020-03-04 13:37 ` Joerg Roedel
2020-03-04 13:37 ` Joerg Roedel
2020-03-04 15:38 ` Jean-Philippe Brucker
2020-03-04 15:38 ` Jean-Philippe Brucker
2020-03-04 17:40 ` Joerg Roedel
2020-03-04 17:40 ` Joerg Roedel
2020-03-04 21:37 ` Jacob Pan (Jun)
2020-03-04 21:37 ` Jacob Pan (Jun)
2020-03-04 21:37 ` Jacob Pan (Jun)
2020-03-04 21:54 ` Joerg Roedel
2020-03-04 21:54 ` Joerg Roedel
2020-03-05 15:42 ` Michael S. Tsirkin
2020-03-05 15:42 ` Michael S. Tsirkin
2020-03-04 15:48 ` Jacob Pan
2020-03-04 15:48 ` Jacob Pan
2020-03-04 17:34 ` Joerg Roedel
2020-03-04 17:34 ` Joerg Roedel
2020-03-04 19:34 ` Michael S. Tsirkin
2020-03-04 19:34 ` Michael S. Tsirkin
2020-03-04 21:50 ` Joerg Roedel
2020-03-04 21:50 ` Joerg Roedel
2020-03-05 15:39 ` Michael S. Tsirkin
2020-03-05 15:39 ` Michael S. Tsirkin
2020-03-03 14:02 ` Michael S. Tsirkin
2020-03-03 14:02 ` Michael S. Tsirkin
2020-03-03 14:02 ` Michael S. Tsirkin
2020-03-05 8:07 ` Tian, Kevin
2020-03-05 8:07 ` Tian, Kevin
2020-03-11 17:48 ` Jean-Philippe Brucker [this message]
2020-03-11 17:48 ` Jean-Philippe Brucker
2020-03-11 21:48 ` Michael S. Tsirkin
2020-03-11 21:48 ` Michael S. Tsirkin
2020-04-13 13:22 ` Michael S. Tsirkin
2020-04-13 13:22 ` Michael S. Tsirkin
2020-04-21 7:31 ` Tian, Kevin
2020-04-21 7:31 ` Tian, Kevin
2020-08-21 8:39 ` Jean-Philippe Brucker
2020-08-21 8:39 ` Jean-Philippe Brucker
2020-08-21 8:39 ` Jean-Philippe Brucker
2020-02-28 17:25 ` [PATCH v2 2/3] PCI: Add DMA configuration for virtual platforms Jean-Philippe Brucker
2020-02-28 17:25 ` Jean-Philippe Brucker
2020-03-18 21:10 ` Bjorn Helgaas
2020-03-18 21:10 ` Bjorn Helgaas
2020-02-28 17:25 ` [PATCH v2 3/3] iommu/virtio: Enable x86 support Jean-Philippe Brucker
2020-02-28 17:25 ` Jean-Philippe Brucker
2020-02-29 14:23 ` kbuild test robot
2020-02-29 14:23 ` kbuild test robot
2020-02-29 14:23 ` kbuild test robot
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=20200311174822.GA96893@myrica \
--to=jean-philippe@linaro.org \
--cc=bhelgaas@google.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--cc=jasowang@redhat.com \
--cc=kevin.tian@intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=mst@redhat.com \
--cc=robin.murphy@arm.com \
--cc=sebastien.boeuf@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.