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

Re: [Xen-devel] [TestDay] Xen crash on boot



On Fri, 2014-01-24 at 13:24 +0000, Jan Beulich wrote:
> >>> On 24.01.14 at 09:34, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> >>>> On 24.01.14 at 01:47, Eric Houby <ehouby@xxxxxxxxx> wrote:
> >> On Thu, 2014-01-23 at 11:16 +0000, Jan Beulich wrote:
> >>> If
> >>> the kernel responds to that mentioned firmware bug by forcing
> >>> interrupt remapping off, maybe we would have to do the same...
> >> 
> >> That would be better than xen failing to boot.
> > 
> > But you realize that, following precedents elsewhere in the
> > IOMMU code, we would disable the IOMMU as a whole rather
> > than just interrupt remapping.
> > 
> > But yes, looking at the Linux side code, I guess we need to do
> > so. Would be nice if you could confirm that the system comes up
> > fine (and hopefully without IOMMU faults) with
> > "iommu=no-intremap,debug" as well as with "iommu=off".
> 
> Here's a patch attempting to do just that. Please give this a try
> without any IOMMU-related override options.
> 
> Jan
> 
> AMD IOMMU: fail if there is no southbridge IO-APIC
> 
> ... 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@xxxxxxx>.
> 
> Reported-by: Eric Houby <ehouby@xxxxxxxxx>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> --- 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) )
> @@ -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;
>  }
>  
> 
> 
> 

Jan,

I am currently using the 4.4.0-RC2 RPMs that are available from the Test
Day information site.  With my limited skill set and time constraints,
it will take me a while to set up for testing the patch.  I will let you
know how it goes.

Thanks,

Eric


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


 


Rackspace

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