[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 12:46 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: > > On 31/07/2019 20:35, Roman Shaposhnik wrote: > > On Wed, Jul 31, 2019 at 1:43 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> > > wrote: > >> On Wed, Jul 31, 2019 at 10:36:31AM +0200, Roger Pau Monné wrote: > >>> On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote: > >>>> Sorry -- got a bit distracted yesterday. Attached is the log with only > >>>> your latest patch attached. Interestingly enough the box booted fine > >>>> without screen artifacts. So I guess we're getting closer... > >>>> > >>>> Thanks for all the help! > >>> That's quite weird, there's no functional changes between the > >>> previous patches and this one, the only difference is that this patch > >>> has more verbose output. > >>> > >>> Are you sure you didn't have any local patches on top of Xen that > >>> could explain this difference in behaviour? > >> FWIW, can you please try the plain patch again: > >> > >> https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg01547.html > >> > >> And report back? > >> > >> I would like to get this committed ASAP if it does fix your issue. > > I'd like to say that it did -- but I tried it again just now and it > > still garbled screen and tons of: > > > > (XEN) printk: 26665 messages suppressed. > > (XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr > > 8e14c000, iommu reg = ffff82c0008de000 > > > > I'm very much confused by what's going on, but it seems that's the > > case -- adding those debug print statements make the issue go away > > > > Here are the patches that are being applied: > > NOT WORKING: > > https://github.com/rvs/eve/blob/xen-bug/pkg/xen/01-iommu-mappings.patch > > > > WORKING: > > https://github.com/rvs/eve/blob/a1291fcd4e669df2a63285afb5e8b4841f45c1c8/pkg/xen/01-iommu-mappings.patch > > > > At this point I'm really not sure what's going on. > > Ok. seeing as you've double checked this, the mystery deepens. > > My bet is on the intel_iommu_lookup_page() call having side effects[1]. > If you take out the debugging in the middle of the loop in > rmrr_identity_mapping(), does the problem reproduce again? > > ~Andrew > > [1] Looking at the internals of addr_to_dma_page_maddr(), it does 100% > more memory allocation and higher-level PTE construction than looks wise > for what is supposed to be a getter. Yup. That's what it is -- intel_iommu_lookup_page() seems to be the culprit. I've did the experiment in the other direction -- adding a dummy call: https://github.com/rvs/eve/blob/36aeeaa7c0a53474fb1ecef2ff587a86637df858/pkg/xen/01-iommu-mappings.patch#L23 on top of original Roger's patch makes system boot NORMALLY. Thanks, Roman. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |