[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Aw: Re: Re: Re: [help] Xen 4.14.5 on Devuan 4.0 Chimaera, regression from Xen 4.0.1
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. Denis
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |