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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Paul 
> Durrant
> Sent: 30 September 2019 17:38
> To: 'Jürgen Groß' <jgross@xxxxxxxx>; 'Jan Beulich' <jbeulich@xxxxxxxx>
> Cc: 'xen-devel@xxxxxxxxxxxxxxxxxxxx' <xen-devel@xxxxxxxxxxxxxxxxxxxx>; 
> 'osstest service owner'
> <osstest-admin@xxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] [xen-unstable test] 141990: regressions - FAIL
> 
> > -----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.
> 

Ok, I think I've figured out the problem. If the h/w is not 'directio' capable 
then libxl__domain_create_info_setdefault() will leave passthrough alone, 
meaning it is still set to 0 == LIBXL_PASSTHROUGH_ENABLED... and then the 
assertion is hit. I'll send a patch shortly.

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