[xen-unstable test] 53884: regressions - FAIL

[xen-unstable test] 53884: regressions - FAIL

[osstest service user]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 10520 bytes --]

flight 53884 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/53884/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm               5 xen-build                 fail REGR. vs. 50405

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64 15 guest-localmigrate.2        fail like 50405
 test-amd64-i386-freebsd10-i386 13 guest-localmigrate           fail like 50405

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-xsm       1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)     blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-xsm        1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)     blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)    blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)    blocked n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start                  fail  never pass
 test-armhf-armhf-libvirt-xsm  6 xen-boot                     fail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start                  fail   never pass
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-xsm       6 xen-boot                     fail   never pass
 test-amd64-i386-libvirt      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop              fail never pass
 test-armhf-armhf-xl          12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-check        fail never pass
 test-armhf-armhf-xl-sedf     12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-stop         fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check        fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 16 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 16 guest-stop               fail never pass
 test-armhf-armhf-libvirt     12 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 16 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 16 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop             fail never pass

version targeted for testing:
 xen                  266fddd0774040096739bf225267f885cfb6b675
baseline version:
 xen                  123c7793797502b222300eb710cd3873dcca41ee

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Chao Peng <chao.p.peng@linux.intel.com>
  Chen Baozi <baozich@gmail.com>
  Christoffer Dall <christoffer.dall@linaro.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Don Slutz <dslutz@verizon.com>
  Edgar E. Iglesias <edgar.iglesias@xilinx.com>
  Emil Condrea <emilcondrea@gmail.com>
  Eugene Korenevsky <ekorenevsky@gmail.com>
  Giuseppe Mazzotta <g.mazzotta@iragan.com>
  Gustau Perez <gustau.perez@gmail.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Campbell <ian.cmapbell@citrix.com>
  Ian Jackson <Ian.Jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Julien Grall <julien.grall@citrix.com>
  Julien Grall <julien.grall@linaro.org>
  Kai Huang <kai.huang@linux.intel.com>
  Kevin Tian <kevin.tian@intel.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Liang Li <liang.z.li@intel.com>
  Linda Jacobson <lindaj@jma3.com>
  Nathan Studer <nate.studer@gmail.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
  Rafał Wojdyła <omeg@invisiblethingslab.com>
  Robert VanVossen <robert.vanvossen@dornerworks.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Ross Lagerwall <ross.lagerwall@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
  Tamas K Lengyel <tamas.lengyel@zentific.com>
  Tamas K Lengyel <tklengyel@sec.in.tum.de>
  Tiejun Chen <tiejun.chen@intel.com>
  Tim Deegan <tim@xen.org>
  Vitaly Kuznetsov <vkuznets@redhat.com>
  Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64-xsm                                              fail
 build-armhf-xsm                                              pass
 build-i386-xsm                                               pass
 build-amd64                                                  pass
 build-armhf                                                  pass
 build-i386                                                   pass
 build-amd64-libvirt                                          pass
 build-armhf-libvirt                                          pass
 build-i386-libvirt                                           pass
 build-amd64-oldkern                                          pass
 build-i386-oldkern                                           pass
 build-amd64-pvops                                            pass
 build-armhf-pvops                                            pass
 build-i386-pvops                                             pass
 build-amd64-rumpuserxen                                      pass
 build-i386-rumpuserxen                                       pass
 test-amd64-amd64-xl                                          pass
 test-armhf-armhf-xl                                          pass
 test-amd64-i386-xl                                           pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm                blocked
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm                 blocked
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm                blocked
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm                 blocked
 test-amd64-amd64-libvirt-xsm                                 blocked
 test-armhf-armhf-libvirt-xsm                                 fail
 test-amd64-i386-libvirt-xsm                                  blocked
 test-amd64-amd64-xl-xsm                                      blocked
 test-armhf-armhf-xl-xsm                                      fail
 test-amd64-i386-xl-xsm                                       blocked
 test-amd64-amd64-xl-pvh-amd                                  fail
 test-amd64-i386-qemut-rhel6hvm-amd                           pass
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass
 test-amd64-i386-freebsd10-amd64                              fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass
 test-amd64-amd64-rumpuserxen-amd64                           pass
 test-amd64-amd64-xl-qemut-win7-amd64                         fail
 test-amd64-i386-xl-qemut-win7-amd64                          fail
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail
 test-amd64-i386-xl-qemuu-win7-amd64                          fail
 test-armhf-armhf-xl-arndale                                  pass
 test-amd64-amd64-xl-credit2                                  pass
 test-armhf-armhf-xl-credit2                                  pass
 test-armhf-armhf-xl-cubietruck                               pass
 test-amd64-i386-freebsd10-i386                               fail
 test-amd64-i386-rumpuserxen-i386                             pass
 test-amd64-amd64-xl-pvh-intel                                fail
 test-amd64-i386-qemut-rhel6hvm-intel                         pass
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass
 test-amd64-amd64-libvirt                                     pass
 test-armhf-armhf-libvirt                                     pass
 test-amd64-i386-libvirt                                      pass
 test-amd64-amd64-xl-multivcpu                                pass
 test-armhf-armhf-xl-multivcpu                                pass
 test-amd64-amd64-pair                                        pass
 test-amd64-i386-pair                                         pass
 test-amd64-amd64-xl-sedf-pin                                 pass
 test-armhf-armhf-xl-sedf-pin                                 pass
 test-amd64-amd64-xl-sedf                                     pass
 test-armhf-armhf-xl-sedf                                     pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail
 test-amd64-amd64-xl-qemut-winxpsp3                           fail
 test-amd64-i386-xl-qemut-winxpsp3                            fail
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail
 test-amd64-i386-xl-qemuu-winxpsp3                            fail


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/osstest/pub/logs
images: /home/osstest/pub/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 2155 lines long.)


[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [xen-unstable test] 53884: regressions - FAIL

[Jan Beulich]

>>> On 09.05.15 at 20:57, <osstest@xenbits.xen.org> wrote:
> flight 53884 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/53884/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-xsm               5 xen-build                 fail REGR. vs. 50405

This is due to e5786bae04 ("x86/pvh: use a custom IO bitmap for
PVH hardware domains"). Having requested th addition during
review I of course took it for granted that you build tested your
change. As dealing with this imo also means moving the code
addition into the already existing (or a new) CONFIG_X86 block
(along with moving the declaration to a more suitable header), I
think a fixup patch would not be the right way to deal with this,
and hence I think I'm going to revert that change for the time
being.

Jan

Re: [xen-unstable test] 53884: regressions - FAIL

[Andrew Cooper]

On 11/05/2015 09:08, Jan Beulich wrote:
>>>> On 09.05.15 at 20:57, <osstest@xenbits.xen.org> wrote:
>> flight 53884 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/53884/ 
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  build-amd64-xsm               5 xen-build                 fail REGR. vs. 50405
> This is due to e5786bae04 ("x86/pvh: use a custom IO bitmap for
> PVH hardware domains"). Having requested th addition during
> review I of course took it for granted that you build tested your
> change. As dealing with this imo also means moving the code
> addition into the already existing (or a new) CONFIG_X86 block
> (along with moving the declaration to a more suitable header), I
> think a fixup patch would not be the right way to deal with this,
> and hence I think I'm going to revert that change for the time
> being.

Given this reversion (and confirmation that the build is fixed), would a
force push be justified?  We are now a full month behind, with other 
OSSTest issues still outstanding.

~Andrew

Re: [xen-unstable test] 53884: regressions - FAIL

[Jan Beulich]

>>> On 11.05.15 at 10:12, <andrew.cooper3@citrix.com> wrote:
> On 11/05/2015 09:08, Jan Beulich wrote:
>>>>> On 09.05.15 at 20:57, <osstest@xenbits.xen.org> wrote:
>>> flight 53884 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/53884/ 
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>  build-amd64-xsm               5 xen-build                 fail REGR. vs. 50405
>> This is due to e5786bae04 ("x86/pvh: use a custom IO bitmap for
>> PVH hardware domains"). Having requested th addition during
>> review I of course took it for granted that you build tested your
>> change. As dealing with this imo also means moving the code
>> addition into the already existing (or a new) CONFIG_X86 block
>> (along with moving the declaration to a more suitable header), I
>> think a fixup patch would not be the right way to deal with this,
>> and hence I think I'm going to revert that change for the time
>> being.
> 
> Given this reversion (and confirmation that the build is fixed), would a
> force push be justified?  We are now a full month behind, with other 
> OSSTest issues still outstanding.

While it'd be really nice to do so, the flight here didn't test the tip of
staging (onto which I'll push the revert in a few minutes), so a force
push may be a little difficult to arrange. I'm also afraid that doing so
would yield the XSM build failure an allowable one going forward.
Otoh, considering that we got two almost-pushes recently, I'm quite
hopeful that we'll get a real push pretty soon.

Jan

Re: [xen-unstable test] 53884: regressions - FAIL

[Ian Campbell]

On Mon, 2015-05-11 at 09:12 +0100, Andrew Cooper wrote:
> On 11/05/2015 09:08, Jan Beulich wrote:
> >>>> On 09.05.15 at 20:57, <osstest@xenbits.xen.org> wrote:
> >> flight 53884 xen-unstable real [real]
> >> http://logs.test-lab.xenproject.org/osstest/logs/53884/ 
> >>
> >> Regressions :-(
> >>
> >> Tests which did not succeed and are blocking,
> >> including tests which could not be run:
> >>  build-amd64-xsm               5 xen-build                 fail REGR. vs. 50405
> > This is due to e5786bae04 ("x86/pvh: use a custom IO bitmap for
> > PVH hardware domains"). Having requested th addition during
> > review I of course took it for granted that you build tested your
> > change. As dealing with this imo also means moving the code
> > addition into the already existing (or a new) CONFIG_X86 block
> > (along with moving the declaration to a more suitable header), I
> > think a fixup patch would not be the right way to deal with this,
> > and hence I think I'm going to revert that change for the time
> > being.
> 
> Given this reversion (and confirmation that the build is fixed), would a
> force push be justified?  We are now a full month behind, with other 
> OSSTest issues still outstanding.

Force pushing would miss out testing the functional aspects of whatever
tests would have run on the other commits in the failed build had it
succeeded.

But given that this is an -xsm build we perhaps don't care so much about
that yet (few of the tests pass yet anyway).

Flight 54309 tested a57b1fff48a8 which is the current staging, and it
failed with the build-amd64-xsm and the freebsd migration thing (which
IMHO we should just whitelist for the time being).

For there to be any possibility of a force push the revert would have to
be the first thing added on top of a57b1fff48a8.

Whatever we do I would suggest killing flight 55228 since it is just
going to fail this build too.

Ian.

Re: [xen-unstable test] 53884: regressions - FAIL

[Ian Campbell]

On Mon, 2015-05-11 at 09:19 +0100, Jan Beulich wrote:
> >>> On 11.05.15 at 10:12, <andrew.cooper3@citrix.com> wrote:
> > On 11/05/2015 09:08, Jan Beulich wrote:
> >>>>> On 09.05.15 at 20:57, <osstest@xenbits.xen.org> wrote:
> >>> flight 53884 xen-unstable real [real]
> >>> http://logs.test-lab.xenproject.org/osstest/logs/53884/ 
> >>>
> >>> Regressions :-(
> >>>
> >>> Tests which did not succeed and are blocking,
> >>> including tests which could not be run:
> >>>  build-amd64-xsm               5 xen-build                 fail REGR. vs. 50405
> >> This is due to e5786bae04 ("x86/pvh: use a custom IO bitmap for
> >> PVH hardware domains"). Having requested th addition during
> >> review I of course took it for granted that you build tested your
> >> change. As dealing with this imo also means moving the code
> >> addition into the already existing (or a new) CONFIG_X86 block
> >> (along with moving the declaration to a more suitable header), I
> >> think a fixup patch would not be the right way to deal with this,
> >> and hence I think I'm going to revert that change for the time
> >> being.
> > 
> > Given this reversion (and confirmation that the build is fixed), would a
> > force push be justified?  We are now a full month behind, with other 
> > OSSTest issues still outstanding.
> 
> While it'd be really nice to do so, the flight here didn't test the tip of
> staging (onto which I'll push the revert in a few minutes), so a force
> push may be a little difficult to arrange.

FWIW flight 54309 did test that.

> I'm also afraid that doing so
> would yield the XSM build failure an allowable one going forward.

I think the proposal was to include the revert in the force push.

> Otoh, considering that we got two almost-pushes recently, I'm quite
> hopeful that we'll get a real push pretty soon.

I would expect so, but I think we should kill in progress flight 55228
as soon as you've pushed the revert.

Ian.

Re: [xen-unstable test] 53884: regressions - FAIL

[Jan Beulich]

>>> On 11.05.15 at 10:19, <JBeulich@suse.com> wrote:
>>>> On 11.05.15 at 10:12, <andrew.cooper3@citrix.com> wrote:
>> On 11/05/2015 09:08, Jan Beulich wrote:
>>>>>> On 09.05.15 at 20:57, <osstest@xenbits.xen.org> wrote:
>>>> flight 53884 xen-unstable real [real]
>>>> http://logs.test-lab.xenproject.org/osstest/logs/53884/ 
>>>>
>>>> Regressions :-(
>>>>
>>>> Tests which did not succeed and are blocking,
>>>> including tests which could not be run:
>>>>  build-amd64-xsm               5 xen-build                 fail REGR. vs. 50405
>>> This is due to e5786bae04 ("x86/pvh: use a custom IO bitmap for
>>> PVH hardware domains"). Having requested th addition during
>>> review I of course took it for granted that you build tested your
>>> change. As dealing with this imo also means moving the code
>>> addition into the already existing (or a new) CONFIG_X86 block
>>> (along with moving the declaration to a more suitable header), I
>>> think a fixup patch would not be the right way to deal with this,
>>> and hence I think I'm going to revert that change for the time
>>> being.
>> 
>> Given this reversion (and confirmation that the build is fixed), would a
>> force push be justified?  We are now a full month behind, with other 
>> OSSTest issues still outstanding.
> 
> While it'd be really nice to do so, the flight here didn't test the tip of
> staging (onto which I'll push the revert in a few minutes), so a force
> push may be a little difficult to arrange. I'm also afraid that doing so
> would yield the XSM build failure an allowable one going forward.
> Otoh, considering that we got two almost-pushes recently, I'm quite
> hopeful that we'll get a real push pretty soon.

And sadly 6ea9f0481e ("xen: guestcopy: Provide an helper to
safely copy string from guest") breaks the x86 XSM build too (due
to type issues with the compat mode layer of flask's hypercall
handling). Reverting that one would be more cumbersome (as I
suppose subsequent changes depend on it), but I very much
hope that you, Julien, will provide a timely fix for this.

Jan

Re: [xen-unstable test] 53884: regressions - FAIL

[Jan Beulich]

>>> On 11.05.15 at 10:29, <ian.campbell@citrix.com> wrote:
> On Mon, 2015-05-11 at 09:19 +0100, Jan Beulich wrote:
>> Otoh, considering that we got two almost-pushes recently, I'm quite
>> hopeful that we'll get a real push pretty soon.
> 
> I would expect so, but I think we should kill in progress flight 55228
> as soon as you've pushed the revert.

Which I've now done.

Jan

Re: [xen-unstable test] 53884: regressions - FAIL

[Jan Beulich]

>>> On 11.05.15 at 10:28, <ian.campbell@citrix.com> wrote:
> Flight 54309 tested a57b1fff48a8 which is the current staging, and it
> failed with the build-amd64-xsm and the freebsd migration thing (which
> IMHO we should just whitelist for the time being).
> 
> For there to be any possibility of a force push the revert would have to
> be the first thing added on top of a57b1fff48a8.

Which is how I (naturally) did it. But as just noted elsewhere - the
revert is not sufficient to fix the XSM build.

Jan

Re: [xen-unstable test] 53884: regressions - FAIL

[Ian Campbell]

On Mon, 2015-05-11 at 09:32 +0100, Jan Beulich wrote:

> > While it'd be really nice to do so, the flight here didn't test the tip of
> > staging (onto which I'll push the revert in a few minutes), so a force
> > push may be a little difficult to arrange. I'm also afraid that doing so
> > would yield the XSM build failure an allowable one going forward.
> > Otoh, considering that we got two almost-pushes recently, I'm quite
> > hopeful that we'll get a real push pretty soon.
> 
> And sadly 6ea9f0481e ("xen: guestcopy: Provide an helper to
> safely copy string from guest") breaks the x86 XSM build too (due
> to type issues with the compat mode layer of flask's hypercall
> handling). Reverting that one would be more cumbersome (as I
> suppose subsequent changes depend on it), but I very much
> hope that you, Julien, will provide a timely fix for this.

Yes, please.

There's no point my killing 55228 until then.

Perhaps I should enable XSM for my precommit build test, I don't want to
do both (life's too short) but building XSM is more likely to be
forgotten by contributors I think.

Ian.

Re: [xen-unstable test] 53884: regressions - FAIL

[Julien Grall]

Hi,

On 11/05/15 10:05, Ian Campbell wrote:
> On Mon, 2015-05-11 at 09:32 +0100, Jan Beulich wrote:
> 
>>> While it'd be really nice to do so, the flight here didn't test the tip of
>>> staging (onto which I'll push the revert in a few minutes), so a force
>>> push may be a little difficult to arrange. I'm also afraid that doing so
>>> would yield the XSM build failure an allowable one going forward.
>>> Otoh, considering that we got two almost-pushes recently, I'm quite
>>> hopeful that we'll get a real push pretty soon.
>>
>> And sadly 6ea9f0481e ("xen: guestcopy: Provide an helper to
>> safely copy string from guest") breaks the x86 XSM build too (due
>> to type issues with the compat mode layer of flask's hypercall
>> handling). Reverting that one would be more cumbersome (as I
>> suppose subsequent changes depend on it), but I very much
>> hope that you, Julien, will provide a timely fix for this.
> 
> Yes, please.
> 
> There's no point my killing 55228 until then.
> 
> Perhaps I should enable XSM for my precommit build test, I don't want to
> do both (life's too short) but building XSM is more likely to be
> forgotten by contributors I think.

Sorry for the breakage, I did test XSM but only with ARM build but I
forgot to do it for x86.

I will send a fix today.

Regards,

-- 
Julien Grall

Re: [xen-unstable test] 53884: regressions - FAIL

[Ian Campbell]

On Mon, 2015-05-11 at 10:05 +0100, Ian Campbell wrote:
> On Mon, 2015-05-11 at 09:32 +0100, Jan Beulich wrote:
> 
> > > While it'd be really nice to do so, the flight here didn't test the tip of
> > > staging (onto which I'll push the revert in a few minutes), so a force
> > > push may be a little difficult to arrange. I'm also afraid that doing so
> > > would yield the XSM build failure an allowable one going forward.
> > > Otoh, considering that we got two almost-pushes recently, I'm quite
> > > hopeful that we'll get a real push pretty soon.
> > 
> > And sadly 6ea9f0481e ("xen: guestcopy: Provide an helper to
> > safely copy string from guest") breaks the x86 XSM build too (due
> > to type issues with the compat mode layer of flask's hypercall
> > handling). Reverting that one would be more cumbersome (as I
> > suppose subsequent changes depend on it), but I very much
> > hope that you, Julien, will provide a timely fix for this.
> 
> Yes, please.
> 
> There's no point my killing 55228 until then.

I've applied Julien's fix and killed this flight.