Re: [help] Xen 4.14.5 on Devuan 4.0 Chimaera, regression from Xen 4.0.1

[Denis <tachyon_gun@xxxxxx>]

On 16.03.2023 16:59, Jan Beulich wrote:
> On 14.03.2023 16:11, Andrew Cooper wrote:
> > On 14/03/2023 2:53 pm, Denis wrote:
> >> On 14.03.2023 07:37; Jan Beulich wrote:
> >>> On 14.03.2023 02:15, Denis wrote:
> >>>> On 13.03.2023 10:36, Jan wrote
> >>>>> On 10.03.2023 21:50, Denis wrote:
> >>>>>> Should I test something else?
> >>>>> ... there was no request for any further testing here, for the moment.
> >>>> ah...sorry, going by "Would be nice to have this confirmed forthe system
> >>>> in question, i.e. without Xen underneath Linux" I thought I could test
> >>>> something which might help shed some light on all of this.
> >>> Well, yes, that Linux-without-Xen test would still be useful to have
> >>> results from. I didn't account for this in my earlier reply because
> >>> I had asked for it before already, and I did take "something else"
> >>> for meaning anything that might have turned up as useful from the new
> >>> data you had provided.
> >> What tests could I do or what info should I provide to help?
> > 
> > Can you please rebuild Xen with this patch:
> > 
> > diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c
> > b/xen/drivers/passthrough/amd/iommu_acpi.c
> > index 2fdebd2d74c9..747eae25f56c 100644
> > --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> > +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> > @@ -1033,7 +1033,7 @@ static int __init parse_ivrs_table(struct
> > acpi_table_header *table)
> >      const struct acpi_ivrs_header *ivrs_block;
> >      unsigned long length;
> >      unsigned int apic;
> > -    bool_t sb_ioapic = !iommu_intremap;
> > +    bool_t sb_ioapic = 1;
> >      int error = 0;
> >  
> >      BUG_ON(!table);
> > 
> > which should cause the behaviour to revert back to that of Xen 4.0.1 
> > (i.e. it will fully ignore the checks relating to the southbridge ioapic).
> 
> Alternatively you may want to try the change below (I think I have now
> convinced myself that the state change is still possible at this point
> in time), with the intended effect of ...
> 
> > Confirm that with this, and booting Xen simply with `iommu=1` that full
> > DMA remapping and interrupt remapping is considered active.
> 
> ... DMA remapping active, but interrupt mapping off (i.e. matching
> Linux behavior), without any overriding command line options.
> 
> Jan
> 
> AMD/IOMMU: allow DMA remapping to remain enabled when there's no southbridge 
> IO-APIC
> 
> The original Linux commit that our respective code was derived from
> isn't as heavyhanded as our cloned code: It only disables interrupt
> remapping in such a case. Follow that model, noting that it is still
> early enough to turn interrupt remapping off on its own.
> 
> Fixes: 06bbcaf48d09 ("AMD IOMMU: fail if there is no southbridge IO-APIC")
> Reported-by: Denis <tachyon_gun@xxxxxx>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> Note that the alternative of disabling per-device interrupt remapping
> is undesirable as per XSA-36, yet then again it may still be better than
> turning off interrupt remapping altogether. Thoughts?
> 
> --- unstable.orig/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ unstable/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -1183,7 +1183,7 @@ static int __init cf_check parse_ivrs_ta
>      if ( !error && !sb_ioapic )
>      {
>          if ( amd_iommu_perdev_intremap )
> -            error = -ENXIO;
> +            iommu_intremap = iommu_intremap_off;
>          printk("%sNo southbridge IO-APIC found in IVRS table\n",
>                 amd_iommu_perdev_intremap ? XENLOG_ERR : XENLOG_WARNING);
>      }

Thank you.

I'll give this a try also and will report back.


Denis