(CC x86 folks)
Hi,
On 09/06/17 12:15, Robin Murphy wrote:
On 08/06/17 20:30, Sameer Goel wrote:
[...]
/**
- * iort_iommu_configure - Set-up IOMMU configuration for a device.
+ * iort_iommu_configure - Set-up IOMMU configuration for a device. This
+ * function sets up the fwspec as needed for a given device. Only PCI
+ * devices are supported for now.
*
* @dev: device to configure
*
- * Returns: iommu_ops pointer on configuration success
- * NULL on configuration failure
+ * Returns: Appropriate acpi_status
*/
-const struct iommu_ops *iort_iommu_configure(struct device *dev)
+acpi_status iort_iommu_configure(struct device *dev)
{
struct acpi_iort_node *node, *parent;
- const struct iommu_ops *ops = NULL;
u32 streamid = 0;
+ acpi_status status = AE_OK;
if (dev_is_pci(dev)) {
- struct pci_bus *bus = to_pci_dev(dev)->bus;
+ struct pci_dev *pci_device = to_pci_dev(dev);
u32 rid;
- pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid,
- &rid);
+ rid = PCI_BDF2(pci_device->bus,pci_device->devfn);
Beware that the Linux code isn't actually correct to begin with[1]. I
don't know how much Xen deals with PCI bridges and quirks, but as it
stands you should be able to trivially expose the flaw here by plugging
in a Marvell 88SE912x-based SATA card and watching either DMA or MSIs
(or even both) kick up stream table faults.
Robin.
[1]:http://www.spinics.net/lists/linux-acpi/msg74844.html
I am not sure how x86 is handling that. The closest I can find would be
domain_context_mapping. I have CCed x86 folks to get more feedback here.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel