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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

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

  Paul

> 
> 
> Juergen

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