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

Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx



On Wed, Jul 31, 2019 at 2:46 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
>
> On 31.07.2019 10:58, Andrew Cooper wrote:
> > On 31/07/2019 09:34, Jan Beulich wrote:
> >> On 30.07.2019 19:56, Roman Shaposhnik wrote:
> >>> On Fri, Jul 26, 2019 at 1:06 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>>> On 23.07.2019 20:25, Roman Shaposhnik wrote:
> >>>>> Interestingly enough, adding iommu_inclusive_mapping=1 AND iommu=debug
> >>>>> booted the system just fine.
> >>>> Btw (I've noticed this only now) - are you saying without "iommu=debug"
> >>>> the box does _not_ boot fine, despite the other option?
> >>> Yes. But it made sense to me since iommu=debug (as per your
> >>> explanation) overwhelms the CPU and I guess adding
> >>> iommu_inclusive_mapping=1 avoids the code path that does it?
> >> I'm afraid I don't follow: My question was whether
> >> "iommu_inclusive_mapping=1" alone would not allow the box to boot.
> >> Without "iommu=debug" there's no excessive logging afaict, no
> >> matter what other IOMMU options you use.
> >
> > Without inclusive mappings, the system boots but the screen is junk and
> > there are DMA faults all over the place.  With inclusive mappings, it
> > all "works" fine.
> >
> > With debug enabled, the DMA faults are spat out to the console for a
> > short while, until an APIC error occurs and the system wedges completely.
>
> Right - the verbosity _with_ "iommu=debug" may be a problem. Hence me
> wondering whether the system indeed wouldn't boot _without_ that option.

Without iommu=debug (and any other option) the screen is garbled.

Thanks,
Roman.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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