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

[Denis <tachyon_gun@xxxxxx>]

On 20.03.2023 12:01, Andrew Cooper wrote:
> On 19/03/2023 7:38 pm, Denis 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).
> >>
> >> Confirm that with this, and booting Xen simply with `iommu=1` that full
> >> DMA remapping and interrupt remapping is considered active.
> >>
> >>
> >> Then, can you play around with passing the soundblaster through to VMs. 
> >> Looking at the LSPCI you provided, it only supports legacy line interrupts.
> >>
> >> Does the device work fine, or do you get a bunch of errors on `xl dmesg`
> >> about IO page faults (which is a generic "IOMMU said no to something"
> >> message)?
> > Sorry, it took my awhile to get it done.
> >
> > The relevant things are enabled again, passthrough works (even the PCI 
> > Audigy2) 
> > and the devices are recognzied in the HVM domU.
> >
> > As you suspected, there are a few IO page faults at the end of the boot 
> > process
> > (from my limited understanding it's maybe related to 
> > "00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus 
> > Controller (rev 41)")
> >
> > I'll attach the "xl dmesg" output file.
> 
> Do you have this file?
> 
> If they're only at the end of boot and not later around passthrough,
> then they might be from other functionality in the Southbridge.

Sorry, my bad, forgot to attach it :(

After booting, the messages appear only ant the end, yet when running the HVM 
domU,
a few lines pop up there as well.

Also, the domU in question seems to use more CPU that it did on the old system.
I don't know if this is a downside of the newer Xen versions and the chnges made
over time. 
 

Denis

Attachment: xl_dmesg_patched_iommu.txt
Description: Text document