[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

 


Rackspace

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