[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0/4] x86/IOMMU: multi-vector MSI prerequisites

>>> On 11.04.13 at 03:51, Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx> 
>>> wrote:
> - From drivers/passthrough/amd/iommu_init.c: enable_iommu(), the 
> enabling code tries to set MSI affinity for IOMMU.
> - From xen/arch/x86/msi.c: set_msi_affinity(), the code tries to 
> "read_msi_msg()" which eventually calls "amd_iommu_read_msi_from_ire()".
> - Please note that the "amd_iommu_read_msi_from_ire()" was originally 
> empty prior the patch.
> - From the patch, the new code try to call "get_intremap_entry()", which 
> is the function that was asserting due to table is NULL.

But even before the patch update_intremap_entry_from_msi_msg()
also necessarily called get_intremap_entry() for the IOMMU device
itself. And the respective write_msi_msg() call follows right after the
read_msi_msg() one, i.e. there's no room for other setup to be done
by that point. Plus the assertion was there already.

> Here, the MSI read message was sent to read IOMMU registers.  Since the 
> message is targeting for IOMMU itself (bdf 0x2 in this case), it should 
> not be remapped.  That is why I believe the interrupt remapping table is 
> empty.

Whether or not the MSI for the IOMMU device itself needs to be
remapped is an independent question, but judging from the
current code as well as from the specification not saying otherwise
it needs to be. Confirmation on this would surely be appreciated
(because otherwise (a) I'd need to understand how this special
case works with the code before the patch and (b) new special
casing may need to be added).

In any case - I think I said this before already - seeing a full log up
to the crash with "iommu=debug" in place might help. After all the
ACPI tables ought to mention the IOMMU PCI device in some way,
and hence there ought to be an IVRS mapping as well as an
associated intremap table. Or else the only way this can work
currently would be by way of find_iommu_for_device() returning
NULL for the IOMMU PCI device (which would mean a similar check
would need to be added to amd_iommu_read_msi_from_ire(), but
it would then be bogus for the failure there to cause a log message
to be issued if iommu_debug - that should be trivial to verify on
an unpatched or older [say 4.2.x based] hypervisor passing


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.