Re: [Xen-devel] [xen-unstable test] 141990: regressions - FAIL

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Paul Durrant
> Sent: 30 September 2019 13:48
> To: 'Jürgen Groß' <jgross@xxxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; osstest service owner 
> <osstest-admin@xxxxxxxxxxxxxx>
> Subject: RE: [Xen-devel] [xen-unstable test] 141990: regressions - FAIL
> 
> > -----Original Message-----
> > From: Jürgen Groß <jgross@xxxxxxxx>
> > Sent: 30 September 2019 10:30
> > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; osstest service owner 
> > <osstest-admin@xxxxxxxxxxxxxx>
> > Subject: Re: [Xen-devel] [xen-unstable test] 141990: regressions - FAIL
> >
> > On 30.09.19 11:17, Paul Durrant wrote:
> > >> -----Original Message-----
> > >> From: Jan Beulich <jbeulich@xxxxxxxx>
> > >> Sent: 30 September 2019 10:07
> > >> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> > >> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Juergen Gross <jgross@xxxxxxxx>; 
> > >> osstest service owner
> > <osstest-
> > >> admin@xxxxxxxxxxxxxx>
> > >> Subject: Re: [Xen-devel] [xen-unstable test] 141990: regressions - FAIL
> > >>
> > >> On 30.09.2019 10:15, Paul Durrant wrote:
> > >>> I can't find anything conclusive in the logs, but it looks like it's 
> > >>> mainly AMD h/w that's the
> > >> problem and on at least one of the test failures I see lots of this kind 
> > >> of thing in the serial
> > log:
> > >>>
> > >>> Sep 29 17:33:55.316422 [  169.828563] AMD-Vi: Event logged [[  
> > >>> 169.831798] IO_PAGE_FAULT
> > >> device=00:13.1 domain=0x0006 address=0x0000000000000080 flags=0x0020]
> > >>> Sep 29 17:33:55.376595 [  169.840481] AMD-Vi: Event logged [[  
> > >>> 169.843716] IO_PAGE_FAULT
> > >> device=00:13.1 domain=0x0006 address=0x0000000000000080 flags=0x0020]
> > >>> Sep 29 17:33:55.388469 [  169.852398] AMD-Vi: Event logged [[  
> > >>> 169.855627] IO_PAGE_FAULT
> > >> device=00:13.1 domain=0x0006 address=0x0000000000000080 flags=0x0020]
> > >>> Sep 29 17:33:55.400486 [  169.864311] AMD-Vi: Event logged [[  
> > >>> 169.867540] IO_PAGE_FAULT
> > >> device=00:13.1 domain=0x0006 address=0x0000000000000080 flags=0x0020]
> > >>> Sep 29 17:33:55.412559 [  169.876224] AMD-Vi: Event logged [[  
> > >>> 169.879458] IO_PAGE_FAULT
> > >> device=00:13.1 domain=0x0006 address=0x0000000000000080 flags=0x0020]
> > >>
> > >
> > > Ah yes, they might be. Still not found anything useful in other logs.
> >
> > One case was for stub-dm, another one for migration.
> >
> > I could imagine info->passthrough isn't initialized properly for the
> > stubdom case, and maybe the information is missing in the migration
> > stream, too?
> 
> Ok, I've verified migration on my Intel test rig. It is fine with 
> passthrough=disabled (or non-
> existent in the xl.cfg) and fails (as expected due to global logdirty 
> refusing to activate when IOMMU
> mappings are present) when set to anything else. Thus the addition of the 
> passthrough setting should
> actually fix failures caused by an earlier patch (when only a global disable 
> could turn off IOMMU
> mappings).
> I have not checked stubdoms yet and I am currently building an AMD system.
> 

stubdom seems to work (although it's broken, possibly for a long time, if you 
try to use a qcow2 system disk image) and AMD seems ok too. So, still no idea 
what breakage osstest has found.

>   Paul
> 
> >
> >
> > Juergen

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