From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH] AMD IOMMU: fail if there is no southbridge IO-APIC Date: Fri, 07 Feb 2014 10:12:17 -0500 Message-ID: <52F4F7D1.9020906@oracle.com> References: <52F4B38C020000780011A15D@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9123913576358413881==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WBn59-0002SY-Uj for xen-devel@lists.xenproject.org; Fri, 07 Feb 2014 15:11:08 +0000 In-Reply-To: <52F4B38C020000780011A15D@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , suravee.suthikulpanit@amd.com List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============9123913576358413881== Content-Type: multipart/alternative; boundary="------------020301070406040603050505" This is a multi-part message in MIME format. --------------020301070406040603050505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/07/2014 04:21 AM, Jan Beulich wrote: > ... but interrupt remapping is requested (with per-device remapping > tables). Without it, the timer interrupt is usually not working. > > Inspired by Linux'es "iommu/amd: Work around wrong IOAPIC device-id in > IVRS table" (commit c2ff5cf5294bcbd7fa50f7d860e90a66db7e5059) by Joerg > Roedel . > > Reported-by: Eric Houby > Signed-off-by: Jan Beulich > Tested-by: Eric Houby > > --- a/xen/drivers/passthrough/amd/iommu_acpi.c > +++ b/xen/drivers/passthrough/amd/iommu_acpi.c > @@ -984,6 +984,7 @@ static int __init parse_ivrs_table(struc > const struct acpi_ivrs_header *ivrs_block; > unsigned long length; > unsigned int apic; > + bool_t sb_ioapic = !iommu_intremap; > int error = 0; > > BUG_ON(!table); > @@ -1017,8 +1018,15 @@ static int __init parse_ivrs_table(struc > /* Each IO-APIC must have been mentioned in the table. */ > for ( apic = 0; !error && iommu_intremap && apic < nr_ioapics; ++apic ) > { > - if ( !nr_ioapic_entries[apic] || > - ioapic_sbdf[IO_APIC_ID(apic)].pin_2_idx ) > + if ( !nr_ioapic_entries[apic] ) > + continue; > + > + if ( !ioapic_sbdf[IO_APIC_ID(apic)].seg && > + /* SB IO-APIC is always on this device in AMD systems. */ > + ioapic_sbdf[IO_APIC_ID(apic)].bdf == PCI_BDF(0, 0x14, 0) ) > + sb_ioapic = 1; > + > + if ( ioapic_sbdf[IO_APIC_ID(apic)].pin_2_idx ) > continue; > > if ( !test_bit(IO_APIC_ID(apic), ioapic_cmdline) ) I don't know whether 0:14:0 is set in stone, I don't remember seeing anywhere that this is architectural. In the (unlikely) event that it is moved somewhere else will the user be able to overwrite where it is? Do you think that sb_ioapic may need to be set to true if appropriate bit is set in ioapic_cmdline? -boris > @@ -1041,6 +1049,14 @@ static int __init parse_ivrs_table(struc > } > } > > + if ( !error && !sb_ioapic ) > + { > + if ( amd_iommu_perdev_intremap ) > + error = -ENXIO; > + printk("%sNo southbridge IO-APIC found in IVRS table\n", > + amd_iommu_perdev_intremap ? XENLOG_ERR : XENLOG_WARNING); > + } > + > return error; > } > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------020301070406040603050505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/07/2014 04:21 AM, Jan Beulich wrote:
... but interrupt remapping is requested (with per-device remapping
tables). Without it, the timer interrupt is usually not working.

Inspired by Linux'es "iommu/amd: Work around wrong IOAPIC device-id in
IVRS table" (commit c2ff5cf5294bcbd7fa50f7d860e90a66db7e5059) by Joerg
Roedel <joerg.roedel@amd.com>.

Reported-by: Eric Houby <ehouby@yahoo.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Eric Houby <ehouby@yahoo.com>

--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -984,6 +984,7 @@ static int __init parse_ivrs_table(struc
     const struct acpi_ivrs_header *ivrs_block;
     unsigned long length;
     unsigned int apic;
+    bool_t sb_ioapic = !iommu_intremap;
     int error = 0;
 
     BUG_ON(!table);
@@ -1017,8 +1018,15 @@ static int __init parse_ivrs_table(struc
     /* Each IO-APIC must have been mentioned in the table. */
     for ( apic = 0; !error && iommu_intremap && apic < nr_ioapics; ++apic )
     {
-        if ( !nr_ioapic_entries[apic] ||
-             ioapic_sbdf[IO_APIC_ID(apic)].pin_2_idx )
+        if ( !nr_ioapic_entries[apic] )
+            continue;
+
+        if ( !ioapic_sbdf[IO_APIC_ID(apic)].seg &&
+             /* SB IO-APIC is always on this device in AMD systems. */
+             ioapic_sbdf[IO_APIC_ID(apic)].bdf == PCI_BDF(0, 0x14, 0) )
+            sb_ioapic = 1;
+
+        if ( ioapic_sbdf[IO_APIC_ID(apic)].pin_2_idx )
             continue;
 
         if ( !test_bit(IO_APIC_ID(apic), ioapic_cmdline) )

I don't know whether 0:14:0 is set in stone, I don't remember seeing anywhere that this is architectural.

In the (unlikely) event that it is moved somewhere else will the user be able to overwrite where it is? Do you
think that sb_ioapic may need to be set to true if appropriate bit is set in ioapic_cmdline?

-boris


@@ -1041,6 +1049,14 @@ static int __init parse_ivrs_table(struc
         }
     }
 
+    if ( !error && !sb_ioapic )
+    {
+        if ( amd_iommu_perdev_intremap )
+            error = -ENXIO;
+        printk("%sNo southbridge IO-APIC found in IVRS table\n",
+               amd_iommu_perdev_intremap ? XENLOG_ERR : XENLOG_WARNING);
+    }
+
     return error;
 }
 






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020301070406040603050505-- --===============9123913576358413881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9123913576358413881==--