Re: [Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-xl-shadow

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf
> Of Paul Durrant
> Sent: 24 August 2018 10:52
> To: Wei Liu <wei.liu2@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Wei Liu <wei.liu2@xxxxxxxxxx>; osstest
> service owner <osstest-admin@xxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-
> xl-shadow
> 
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> > Sent: 24 August 2018 10:50
> > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> > Cc: Wei Liu <wei.liu2@xxxxxxxxxx>; osstest service owner <osstest-
> > admin@xxxxxxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> > Subject: Re: [Xen-devel] [linux-3.18 bisection] complete test-amd64-
> amd64-
> > xl-shadow
> >
> > On Fri, Aug 24, 2018 at 10:44:09AM +0100, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> > > > Sent: 24 August 2018 10:38
> > > > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> > > > Cc: Wei Liu <wei.liu2@xxxxxxxxxx>; osstest service owner <osstest-
> > > > admin@xxxxxxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> > > > Subject: Re: [Xen-devel] [linux-3.18 bisection] complete test-amd64-
> > amd64-
> > > > xl-shadow
> > > >
> > > > On Fri, Aug 24, 2018 at 10:35:52AM +0100, Paul Durrant wrote:
> > > > > > -----Original Message-----
> > > > > > From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> > > > > > Sent: 24 August 2018 10:35
> > > > > > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> > > > > > Cc: Wei Liu <wei.liu2@xxxxxxxxxx>; osstest service owner <osstest-
> > > > > > admin@xxxxxxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> > > > > > Subject: Re: [Xen-devel] [linux-3.18 bisection] complete test-
> amd64-
> > > > amd64-
> > > > > > xl-shadow
> > > > > >
> > > > > > On Fri, Aug 24, 2018 at 10:30:26AM +0100, Paul Durrant wrote:
> > > > > > > > > For bisection revision-tuple graph see:
> > > > > > > > >    http://logs.test-
> > lab.xenproject.org/osstest/results/bisect/linux-
> > > > > > > > 3.18/test-amd64-amd64-xl-shadow.guest-start.html
> > > > > > > > > Revision IDs in each graph node refer, respectively, to the
> Trees
> > > > above.
> > > > > > > >
> > > > > > > > domainbuilder: detail: vcpu_x86_64: called
> > > > > > > > domainbuilder: detail: vcpu_x86_64: cr3: pfn 0x2245 mfn
> 0x244845
> > > > > > > > xenforeignmemory: error: ioctl failed: Invalid argument
> > > > > > > > xc: error: panic: xc_dom_boot.c:420: xc_dom_gnttab_seed:
> failed
> > to
> > > > > > acquire
> > > > > > > > d1 grant table [errno=22]
> > > > > > > > : Internal error
> > > > > > > > libxl: error: libxl_dom.c:750:libxl__build_dom:
> > xc_dom_gnttab_init
> > > > failed:
> > > > > > > > Invalid argument
> > > > > > > > domainbuilder: detail: xc_dom_release: called
> > > > > > > >
> > > > > > >
> > > > > > > Taking a look now... Just forcing hap off doesn't generate an
> > immediate
> > > > > > repro so I'll have to have a closer look at the environment.
> > > > > >
> > > > > > Note the Linux branch is 3.18. I'm not sure if that really matters.
> > > > > >
> > > > >
> > > > > I think that's the guest version, which should be irrelevant. Trying 
> > > > > to
> > figure
> > > > out from the logs what dom0 is.
> > > >
> > > > No. That's the host kernel.
> > > >
> > >
> > > Ok. Got a repro with my base debian 4.9 dom0 kernel:
> > >
> > > xenforeignmemory: error: ioctl failed: Invalid argument
> > > xc: error: panic: xc_dom_boot.c:420: xc_dom_gnttab_seed: failed to
> > acquire d1 grant table [errno=22]
> > > : Internal error
> > > libxl: error: libxl_dom.c:750:libxl__build_dom: xc_dom_gnttab_init failed:
> > Invalid argument
> > > domainbuilder: detail: xc_dom_release: called
> > > libxl: error: libxl_create.c:1266:domcreate_rebuild_done: Domain
> 1:cannot
> > (re-)build domain: -3
> > > libxl: error: libxl_domain.c:1034:libxl__destroy_domid: Domain 1:Non-
> > existant domain
> > > libxl: error: libxl_domain.c:993:domain_destroy_callback: Domain
> 1:Unable
> > to destroy guest
> > > libxl: error: libxl_domain.c:920:domain_destroy_cb: Domain 1:Destruction
> > of domain failed
> > >
> > > I'm guessing it is a straight bug in the fall-back that's supposed to 
> > > happen
> if
> > privcmd doesn't do resource mapping.
> >
> > There are a lot of failed tests for the same step  on 4.9 branch as
> > well. I guess that is caused by the same issue.
> 
> It's looking like privcmd is failing the ioctl with EINVAL rather than ENOTTY 
> or
> EOPNOTSUPP for some reason. I'll need to look at the older privcmd source.
> 

Yep, it was a bug in privcmd. I fixed it in 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/xen/privcmd.c?id=dc9eab6fd94dd26340749321bba2c58634761516
 but we're clearly going to need to tolerate the old behaviour. I'll send a 
patch shortly.

  Paul

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