[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



Hi Roger!

Some good news, some bad news ;-)

Good news is that on the newer BIOS, your original patch seems to work fine.

IOW, with newer BIOS:
    1. without your original patch I see garbled screen
    2. with your original patch everything boots normally.

Bad news is that with older BIOS, your original patch seems to either
work or not depending on the BIOS some of the BIOS settings.

IOW, with older BIOS:
    1. without your original patch I see garbled screen (regardless of
BIOS settings)
    2. with your original patch AND resetting to a factory defaults of
BIOS settings -- everything boots normally
    3. when I load up our custom settings -- the only thing that can
boot normally is the latest patch

So, would it make sense and commit your original patch for now? This
will unlock me with newer BIOSes on these boxes.

As for the older BIOSes, I still feel that it would be great for Xen
to boot more reliably -- especially since Xen 4.10 seems to be doing
fine regardless of BIOS version and settings.

What do you think?

Btw, just to be clear -- when I say your original patch here's what I mean:

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index fef97c82f6..3605614aaf 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1341,7 +1341,7 @@ int set_identity_p2m_entry(struct domain *d,
unsigned long gfn_l,

     if ( !paging_mode_translate(p2m->domain) )
     {
-        if ( !need_iommu_pt_sync(d) )
+        if ( !has_iommu_pt(d) )
             return 0;
         return iommu_legacy_map(d, _dfn(gfn_l), _mfn(gfn_l), PAGE_ORDER_4K,
                                 IOMMUF_readable | IOMMUF_writable);
@@ -1432,7 +1432,7 @@ int clear_identity_p2m_entry(struct domain *d,
unsigned long gfn_l)

     if ( !paging_mode_translate(d) )
     {
-        if ( !need_iommu_pt_sync(d) )
+        if ( !has_iommu_pt(d) )
             return 0;
         return iommu_legacy_unmap(d, _dfn(gfn_l), PAGE_ORDER_4K);
     }

Thanks,
Roman.

On Wed, Aug 14, 2019 at 1:06 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>
> On Tue, Aug 13, 2019 at 12:24:32PM -0700, Roman Shaposhnik wrote:
> > Hi Roger,
> >
> > sorry for the delay -- I hope you will understand that I actually had
> > a good reason. See below:
>
> No problem, just wanted to make sure this doesn't fell through the
> cracks.
>
> > On Mon, Aug 12, 2019 at 1:57 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> 
> > wrote:
> > >
> > > Ping?
> > >
> > > I know I've posted this quite recently, but have you been able to test
> > > the two proposed patches?
> > >
> > > ie: the one here and:
> > >
> > > https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00643.html
> > >
> > > I would like to figure out exactly what's going on and fix this
> > > properly.
> >
> > Turns out this may actually be related to the BIOS version on these
> > boxes. I have
> > one with the BIOS build from 06/07/2018 and the other one is from 2017. So 
> > with
> > 2 of your proposed patches -- we now have a 2x2 test matrix. The awful
> > part seems
> > to be that the behavior looks to be slightly different.
> >
> > I need an extra day to summarize it all and I'll follow up quickly. It
> > just so far I lost
> > time trying to figure out while the same build would behave
> > differently on different
> > boxes only to find out that the BIOS is different (and the really
> > awful part is that
> > they both report as version 5.0.1.1 -- it is only when you look at the 
> > timestamp
> > of the build -- that's where you see them being different :-( ).
>
> Oh, that's awful. I hope you can get something clear out of this.
>
> Roger.

_______________________________________________
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®.