thr3ads.net - Xen devel - [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd [Feb 2012]

If this information is useful, please help other people find it:
Share via:

xen.org

2012-Feb-25 00:56 UTC

[xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-amd
test redhat-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39


  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
  
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 12043 fail [host=potato-beetle] / 12031 ok.
Failure / basis pass flights: 12043 / 12031
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
Generating revisions with ./adhoc-revtuple-generator 
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a
git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b95c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc
http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-0c3d19f40ab1
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 59 nodes in revision graph
Searching for test results:
 12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
 12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
 12044 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12047 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
 12049 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
 12050 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
 12051 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12052 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12054 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
 12055 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12056 blocked 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12057 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12059 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12060 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
Searching for interesting versions
 Result found: flight 12024 (pass), for basis pass
 Result found: flight 12043 (fail), for basis failure
 Repro found: flight 12044 (pass), for basis pass
 Repro found: flight 12054 (fail), for basis failure
 0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
128de2549c5f24e4a437b86bd2e46f023976d50a
86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
No revisions left to test, checking graph state.
 Result found: flight 12051 (pass), for last pass
 Result found: flight 12052 (fail), for first failure
 Repro found: flight 12055 (pass), for last pass
 Repro found: flight 12057 (fail), for first failure
 Repro found: flight 12059 (pass), for last pass
 Repro found: flight 12060 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in
/home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.redhat-install.{dot,ps,png,html}.
----------------------------------------
12060: ALL FAIL

flight 12060 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12060/


jobs:
 test-amd64-i386-rhel6hvm-amd                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

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

Jan Beulich

2012-Feb-27 09:03 UTC

head link

Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

>>> On 25.02.12 at 01:56, xen.org <ian.jackson@eu.citrix.com>
wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-rhel6hvm-amd
> test redhat-install
> 
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg 
> 
> *** Found and reproduced problem changeset ***
I had warned a number of times that a change like this should not be
done: Afaict, this broke qemu-xen (and upstream qemu as well), which
use BLKIF_MAX_SEGMENTS_PER_REQUEST without caring to set a
specific __XEN_INTERFACE_VERSION__ (the tools generally just use
''latest'').

The same would go for tools/blktap*/.

So either all uses within tools land get properly fixed (which is going to
be particularly hard to synchronize with upstream qemu), or (my
preference) the change gets reverted and done backward
compatibly without involving __XEN_INTERFACE_VERSION__.

Jan
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg 
>   Bug introduced:  a59c1dcfe968
>   Bug not present: f9789db96c39
> 
> 
>   changeset:   24875:a59c1dcfe968
>   user:        Justin T. Gibbs <justing@spectralogic.com>
>   date:        Thu Feb 23 10:03:07 2012 +0000
>       
>       blkif.h: Define and document the request number/size/segments 
> extension
>       
>       Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>             BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
>             updated to, at minimum, use
BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
>             before being recompiled with a __XEN_INTERFACE_VERSION greater
>             than or equal to this value.
>       
>       This extension first appeared in the FreeBSD Operating System.
>       
>       Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
>       Committed-by: Keir Fraser <keir@xen.org>
>       
>       
> 
> 
> For bisection revision-tuple graph see:
>    
>
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-
> amd64-i386-rhel6hvm-amd.redhat-install.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> ----------------------------------------
> Searching for failure / basis pass:
>  12043 fail [host=potato-beetle] / 12031 ok.
> Failure / basis pass flights: 12043 / 12031
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg 
> Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
> Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
> Generating revisions with ./adhoc-revtuple-generator  
>
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71
> d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
>
git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e
> 46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a 
>
git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b9
> 5c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc 
> http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-0c3d19f40ab1 
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> Loaded 59 nodes in revision graph
> Searching for test results:
>  12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
>  12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
>  12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
>  12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
>  12044 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
>  12047 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
>  12049 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
>  12050 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
>  12051 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
>  12052 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
>  12054 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
>  12055 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
>  12056 blocked 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
>  12057 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
>  12059 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
>  12060 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
> Searching for interesting versions
>  Result found: flight 12024 (pass), for basis pass
>  Result found: flight 12043 (fail), for basis failure
>  Repro found: flight 12044 (pass), for basis pass
>  Repro found: flight 12054 (fail), for basis failure
>  0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
> No revisions left to test, checking graph state.
>  Result found: flight 12051 (pass), for last pass
>  Result found: flight 12052 (fail), for first failure
>  Repro found: flight 12055 (pass), for last pass
>  Repro found: flight 12057 (fail), for first failure
>  Repro found: flight 12059 (pass), for last pass
>  Repro found: flight 12060 (fail), for first failure
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg 
>   Bug introduced:  a59c1dcfe968
>   Bug not present: f9789db96c39
> 
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> 
>   changeset:   24875:a59c1dcfe968
>   user:        Justin T. Gibbs <justing@spectralogic.com>
>   date:        Thu Feb 23 10:03:07 2012 +0000
>       
>       blkif.h: Define and document the request number/size/segments 
> extension
>       
>       Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>             BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
>             updated to, at minimum, use
BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
>             before being recompiled with a __XEN_INTERFACE_VERSION greater
>             than or equal to this value.
>       
>       This extension first appeared in the FreeBSD Operating System.
>       
>       Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
>       Committed-by: Keir Fraser <keir@xen.org>
>       
>       
> 
> Revision graph left in 
>
/home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.re
> dhat-install.{dot,ps,png,html}.
> ----------------------------------------
> 12060: ALL FAIL
> 
> flight 12060 xen-unstable real-bisect [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12060/ 
> 
> 
> jobs:
>  test-amd64-i386-rhel6hvm-amd                                 fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs 
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel

Ian Campbell

2012-Feb-27 09:32 UTC

head link

Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

On Mon, 2012-02-27 at 09:03 +0000, Jan Beulich wrote:> >>> On 25.02.12 at 01:56, xen.org
<ian.jackson@eu.citrix.com> wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-amd64-i386-rhel6hvm-amd
> > test redhat-install
> > 
> > Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> > Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg 
> > 
> > *** Found and reproduced problem changeset ***
> 
> I had warned a number of times that a change like this should not be
> done: Afaict, this broke qemu-xen (and upstream qemu as well), which
> use BLKIF_MAX_SEGMENTS_PER_REQUEST without caring to set a
> specific __XEN_INTERFACE_VERSION__ (the tools generally just use
> ''latest'').
Yes, we should have better foreseen this, especially given that you were
trying to tell us what we should see!

AFAICT the places which needed changing are:
      * mini-os
      * qemu-xen-traditional
      * qemu-xen (upstream)

A patch (untested, but mostly done via sed) for mini-os follows. This
one really ought to have been forseen.

I was surprised that qemu (particularly upstream qemu) is building
against the Xen headers using __XEN_INTERFACE_VERSION__.

I think it is not worth fixing this for qemu-xen-traditional, so I will
follow up with the
> The same would go for tools/blktap*/.
That one never occurred to me, even after I grepped for the symbol.
> So either all uses within tools land get properly fixed (which is going to
> be particularly hard to synchronize with upstream qemu),
IMHO upstream qemu should either include it''s own copy of the i/o
interface headers that it uses or it should use a specific
__XEN_INTERFACE_VERSION__. Is this something which is wrong with the
qemu tree or is it the Xen build system integration which is at fault?

I''ll followup with a quick fix but IMHO it could be done better.
>  or (my
> preference) the change gets reverted and done backward
> compatibly without involving __XEN_INTERFACE_VERSION__.
Given that it is blocking the test gate I think reverting it should be
strongly considered. As for how best to do this properly I have less of
an opinion.

That mini-os fix:

8<----------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330335066 0
# Node ID f351fec6d3960d537dde2cb35374982f6ea13e16
# Parent  a4ef50b6313066d953314969494654f4f393558a
mini-os: Fix breakage causes by blkif.h interface change.

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs reflecting in mini-os.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a4ef50b63130 -r f351fec6d396 extras/mini-os/blkfront.c
--- a/extras/mini-os/blkfront.c	Sat Feb 25 09:36:19 2012 +0000
+++ b/extras/mini-os/blkfront.c	Mon Feb 27 09:31:06 2012 +0000
@@ -352,7 +352,7 @@ void blkfront_aio(struct blkfront_aiocb 
 
     /* qemu''s IDE max multsect is 16 (8KB) and SCSI max DMA was set to
32KB,
      * so max 44KB can''t happen */
-    ASSERT(n <= BLKIF_MAX_SEGMENTS_PER_REQUEST);
+    ASSERT(n <= BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK);
 
     blkfront_wait_slot(dev);
     i = dev->ring.req_prod_pvt;
diff -r a4ef50b63130 -r f351fec6d396 extras/mini-os/include/blkfront.h
--- a/extras/mini-os/include/blkfront.h	Sat Feb 25 09:36:19 2012 +0000
+++ b/extras/mini-os/include/blkfront.h	Mon Feb 27 09:31:06 2012 +0000
@@ -12,7 +12,7 @@ struct blkfront_aiocb
     uint8_t is_write;
     void *data;
 
-    grant_ref_t gref[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    grant_ref_t gref[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     int n;
 
     void (*aio_cb)(struct blkfront_aiocb *aiocb, int ret);

Ian Campbell

2012-Feb-27 09:34 UTC

head link

[PATCH qemu-xen-traditional] Fix after blkif.h update

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs to be reflected here.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 block-vbd.c    |    2 +-
 hw/e1000.c     |    3 +++
 hw/ide.c       |    2 +-
 hw/scsi-disk.c |    2 +-
 hw/xen_blkif.h |    8 ++++----
 hw/xen_disk.c  |   12 ++++++------
 6 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/block-vbd.c b/block-vbd.c
index 71f1731..2a80f09 100644
--- a/block-vbd.c
+++ b/block-vbd.c
@@ -33,7 +33,7 @@
 
 #include <xen/io/blkif.h>
 #define IDE_DMA_BUF_SECTORS \
-	(((BLKIF_MAX_SEGMENTS_PER_REQUEST - 1 ) * TARGET_PAGE_SIZE) / 512)
+	(((BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK - 1 ) * TARGET_PAGE_SIZE) / 512)
 #define IDE_DMA_BUF_BYTES (IDE_DMA_BUF_SECTORS * 512)
 #define SECTOR_SIZE 512
 
diff --git a/hw/e1000.c b/hw/e1000.c
index bb3689e..97104ed 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -444,6 +444,8 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
             bytes = split_size;
             if (tp->size + bytes > msh)
                 bytes = msh - tp->size;
+
+            bytes = MIN(sizeof(tp->data) - tp->size, bytes);
             cpu_physical_memory_read(addr, tp->data + tp->size, bytes);
             if ((sz = tp->size + bytes) >= hdr && tp->size
< hdr)
                 memmove(tp->header, tp->data, hdr);
@@ -459,6 +461,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
         // context descriptor TSE is not set, while data descriptor TSE is set
         DBGOUT(TXERR, "TCP segmentaion Error\n");
     } else {
+        split_size = MIN(sizeof(tp->data) - tp->size, split_size);
         cpu_physical_memory_read(addr, tp->data + tp->size, split_size);
         tp->size += split_size;
     }
diff --git a/hw/ide.c b/hw/ide.c
index 791666b..c3d3d60 100644
--- a/hw/ide.c
+++ b/hw/ide.c
@@ -209,7 +209,7 @@
 #ifdef CONFIG_STUBDOM
 #include <xen/io/blkif.h>
 #define IDE_DMA_BUF_SECTORS \
-	(((BLKIF_MAX_SEGMENTS_PER_REQUEST - 1 ) * TARGET_PAGE_SIZE) / 512)
+	(((BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK - 1 ) * TARGET_PAGE_SIZE) / 512)
 #else
 #define IDE_DMA_BUF_SECTORS 256
 #endif
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 520009e..99c2cdf 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -42,7 +42,7 @@ do { fprintf(stderr, "scsi-disk: " fmt , ##args); }
while (0)
 
 #ifdef CONFIG_STUBDOM
 #include <xen/io/blkif.h>
-#define SCSI_DMA_BUF_SIZE    ((BLKIF_MAX_SEGMENTS_PER_REQUEST - 1) *
TARGET_PAGE_SIZE)
+#define SCSI_DMA_BUF_SIZE    ((BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK - 1) *
TARGET_PAGE_SIZE)
 #else
 #define SCSI_DMA_BUF_SIZE    131072
 #endif
diff --git a/hw/xen_blkif.h b/hw/xen_blkif.h
index ca3a65b..485a166 100644
--- a/hw/xen_blkif.h
+++ b/hw/xen_blkif.h
@@ -24,7 +24,7 @@ struct blkif_x86_32_request {
 	blkif_vdev_t   handle;       /* only for read/write requests         */
 	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 struct blkif_x86_32_response {
 	uint64_t        id;              /* copied from request */
@@ -42,7 +42,7 @@ struct blkif_x86_64_request {
 	blkif_vdev_t   handle;       /* only for read/write requests         */
 	uint64_t       __attribute__((__aligned__(8))) id;
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 struct blkif_x86_64_response {
 	uint64_t       __attribute__((__aligned__(8))) id;
@@ -72,7 +72,7 @@ enum blkif_protocol {
 
 static inline void blkif_get_x86_32_req(blkif_request_t *dst,
blkif_x86_32_request_t *src)
 {
-	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
 
 	dst->operation = src->operation;
 	dst->nr_segments = src->nr_segments;
@@ -87,7 +87,7 @@ static inline void blkif_get_x86_32_req(blkif_request_t *dst,
blkif_x86_32_reque
 
 static inline void blkif_get_x86_64_req(blkif_request_t *dst,
blkif_x86_64_request_t *src)
 {
-	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
 
 	dst->operation = src->operation;
 	dst->nr_segments = src->nr_segments;
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 6aebb77..092def8 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -55,7 +55,7 @@ static int use_aio      = 0;
 /* ------------------------------------------------------------- */
 
 #define BLOCK_SIZE  512
-#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
+#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK + 2)
 
 struct ioreq {
     blkif_request_t     req;
@@ -68,10 +68,10 @@ struct ioreq {
     int                 postsync;
 
     /* grant mapping */
-    uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-    uint32_t            refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
+    uint32_t            refs[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     int                 prot;
-    void                *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    void                *page[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     void                *pages;
 
     /* aio status */
@@ -127,7 +127,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
 	ioreq = qemu_mallocz(sizeof(*ioreq));
 	ioreq->blkdev = blkdev;
 	blkdev->requests_total++;
-        qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+        qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK);
     } else {
 	/* get one from freelist */
 	ioreq = LIST_FIRST(&blkdev->freelist);
@@ -207,7 +207,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 
     ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
     for (i = 0; i < ioreq->req.nr_segments; i++) {
-	if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+	if (i == BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK) {
 	    xen_be_printf(&blkdev->xendev, 0, "error: nr_segments too
big\n");
 	    goto err;
 	}
-- 
1.7.2.5

Ian Campbell

2012-Feb-27 09:36 UTC

head link

[PATCH qemu-xen] Fix after blkif.h update

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs reflecting here. A compatibility definition is included in order to keep
building with older versions of the headers.

IMHO qemu should contain a copy of the interface headers of its own so that it
can update at its own pace (like most guest OSes do).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 hw/xen_blkif.h |   13 +++++++++----
 hw/xen_disk.c  |   12 ++++++------
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/hw/xen_blkif.h b/hw/xen_blkif.h
index c0f4136..5db8319 100644
--- a/hw/xen_blkif.h
+++ b/hw/xen_blkif.h
@@ -5,6 +5,11 @@
 #include <xen/io/blkif.h>
 #include <xen/io/protocols.h>
 
+/* Compatibility with older blkif headers */
+#ifndef BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK BLKIF_MAX_SEGMENTS_PER_REQUEST
+#endif
+
 /* Not a real protocol.  Used to generate ring structs which contain
  * the elements common to all protocols only.  This way we get a
  * compiler-checkable way to use common struct elements, so we can
@@ -24,7 +29,7 @@ struct blkif_x86_32_request {
 	blkif_vdev_t   handle;       /* only for read/write requests         */
 	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 struct blkif_x86_32_response {
 	uint64_t        id;              /* copied from request */
@@ -42,7 +47,7 @@ struct blkif_x86_64_request {
 	blkif_vdev_t   handle;       /* only for read/write requests         */
 	uint64_t       __attribute__((__aligned__(8))) id;
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 struct blkif_x86_64_response {
 	uint64_t       __attribute__((__aligned__(8))) id;
@@ -72,7 +77,7 @@ enum blkif_protocol {
 
 static inline void blkif_get_x86_32_req(blkif_request_t *dst,
blkif_x86_32_request_t *src)
 {
-	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
 
 	dst->operation = src->operation;
 	dst->nr_segments = src->nr_segments;
@@ -87,7 +92,7 @@ static inline void blkif_get_x86_32_req(blkif_request_t *dst,
blkif_x86_32_reque
 
 static inline void blkif_get_x86_64_req(blkif_request_t *dst,
blkif_x86_64_request_t *src)
 {
-	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
 
 	dst->operation = src->operation;
 	dst->nr_segments = src->nr_segments;
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 286bbac..0f22bc6 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -54,7 +54,7 @@ static int use_aio      = 1;
 /* ------------------------------------------------------------- */
 
 #define BLOCK_SIZE  512
-#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
+#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK + 2)
 
 struct ioreq {
     blkif_request_t     req;
@@ -67,10 +67,10 @@ struct ioreq {
     int                 postsync;
 
     /* grant mapping */
-    uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-    uint32_t            refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
+    uint32_t            refs[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     int                 prot;
-    void                *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    void                *page[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     void                *pages;
 
     /* aio status */
@@ -128,7 +128,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
         ioreq = g_malloc0(sizeof(*ioreq));
         ioreq->blkdev = blkdev;
         blkdev->requests_total++;
-        qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+        qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK);
     } else {
         /* get one from freelist */
         ioreq = QLIST_FIRST(&blkdev->freelist);
@@ -210,7 +210,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 
     ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
     for (i = 0; i < ioreq->req.nr_segments; i++) {
-        if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+        if (i == BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK) {
             xen_be_printf(&blkdev->xendev, 0, "error: nr_segments
too big\n");
             goto err;
         }
-- 
1.7.2.5

Ian Campbell

2012-Feb-27 09:43 UTC

head link

Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

On Mon, 2012-02-27 at 09:32 +0000, Ian Campbell wrote:> > The same would go for tools/blktap*/.
> 
> That one never occurred to me, even after I grepped for the symbol.
I guess the following ought to fix it...

8<---------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330335804 0
# Node ID 42978617757ff3c8fce5c6d1873ad86d46c594ae
# Parent  0bb45a06c1a8b049dba322cfb91c86c253068f0e
blktap: Fix after blkif.h update

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs to be reflected here Fix after blkif.h update

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap/lib/blktaplib.h
--- a/tools/blktap/lib/blktaplib.h	Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap/lib/blktaplib.h	Mon Feb 27 09:43:24 2012 +0000
@@ -230,10 +230,10 @@ int setup_probe_watch(struct xs_handle *
 
 /* Accessing attached data page mappings */
 #define MMAP_PAGES                                              \
-    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
+    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
 #define MMAP_VADDR(_vstart,_req,_seg)                                   \
     ((_vstart) +                                              \
-     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +    \
+     ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) +    \
      ((_seg) * getpagesize()))
 
 
diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-diff.c
--- a/tools/blktap2/drivers/tapdisk-diff.c	Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap2/drivers/tapdisk-diff.c	Mon Feb 27 09:43:24 2012 +0000
@@ -429,7 +429,7 @@ tapdisk_stream_enqueue1(void)
 		breq->sector_number = sreq->sec;
 		breq->operation     = BLKIF_OP_READ;
 
-		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
+		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
 			uint32_t secs;
 			struct blkif_request_segment *seg = breq->seg + i;
 
diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-stream.c
--- a/tools/blktap2/drivers/tapdisk-stream.c	Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap2/drivers/tapdisk-stream.c	Mon Feb 27 09:43:24 2012 +0000
@@ -296,7 +296,7 @@ tapdisk_stream_enqueue(event_id_t id, ch
 		breq->sector_number = sreq->sec;
 		breq->operation     = BLKIF_OP_READ;
 
-		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
+		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
 			uint32_t secs = MIN(s->end - s->cur, psize >> SECTOR_SHIFT);
 			struct blkif_request_segment *seg = breq->seg + i;
 
diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/include/blktaplib.h
--- a/tools/blktap2/include/blktaplib.h	Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap2/include/blktaplib.h	Mon Feb 27 09:43:24 2012 +0000
@@ -222,10 +222,10 @@ typedef struct msg_lock {
 
 /* Accessing attached data page mappings */
 #define MMAP_PAGES                                                    \
-    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
+    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
 #define MMAP_VADDR(_vstart,_req,_seg)                                 \
     ((_vstart) +                                                      \
-     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +      \
+     ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) +      \
      ((_seg) * getpagesize()))
 
 /* Defines that are only used by library clients */

Jan Beulich

2012-Feb-27 09:52 UTC

head link

Re: [PATCH qemu-xen-traditional] Fix after blkif.h update

>>> On 27.02.12 at 10:34, Ian Campbell <Ian.Campbell@citrix.com>
wrote:
> diff --git a/hw/e1000.c b/hw/e1000.c
> index bb3689e..97104ed 100644
> --- a/hw/e1000.c
> +++ b/hw/e1000.c
> @@ -444,6 +444,8 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc
*dp)
>              bytes = split_size;
>              if (tp->size + bytes > msh)
>                  bytes = msh - tp->size;
> +
> +            bytes = MIN(sizeof(tp->data) - tp->size, bytes);
>              cpu_physical_memory_read(addr, tp->data + tp->size,
bytes);
>              if ((sz = tp->size + bytes) >= hdr &&
tp->size < hdr)
>                  memmove(tp->header, tp->data, hdr);
> @@ -459,6 +461,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc
*dp)
>          // context descriptor TSE is not set, while data descriptor TSE is
set
>          DBGOUT(TXERR, "TCP segmentaion Error\n");
>      } else {
> +        split_size = MIN(sizeof(tp->data) - tp->size, split_size);
>          cpu_physical_memory_read(addr, tp->data + tp->size,
split_size);
>          tp->size += split_size;
>      }
What are these two changes doing here?

Jan

Jan Beulich

2012-Feb-27 10:00 UTC

head link

Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

>>> On 27.02.12 at 10:32, Ian Campbell <Ian.Campbell@citrix.com>
wrote:
> On Mon, 2012-02-27 at 09:03 +0000, Jan Beulich wrote:
>>  or (my
>> preference) the change gets reverted and done backward
>> compatibly without involving __XEN_INTERFACE_VERSION__.
> 
> Given that it is blocking the test gate I think reverting it should be
> strongly considered. As for how best to do this properly I have less of
> an opinion.
It''s not only the blocking of the test gate: The kind of (unforeseen)
fallout we''re having in our own tree should make us ask ourselves
again whether risking to break other people''s code (who may have
just followed what we''re doing) is worth it. This includes the (bogus
imo, as pointed out before) tying of io/* definitions to particular
__XEN_INTERFACE_VERSION__ values - each I/O interface should
be completely standalone.

Jan

Keir Fraser

2012-Feb-27 12:11 UTC

head link

Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

On 27/02/2012 09:32, "Ian Campbell" <Ian.Campbell@citrix.com>
wrote:
>>  or (my
>> preference) the change gets reverted and done backward
>> compatibly without involving __XEN_INTERFACE_VERSION__.
> 
> Given that it is blocking the test gate I think reverting it should be
> strongly considered. As for how best to do this properly I have less of
> an opinion.
I reverted it for now at least. Perhaps it makes sense to do this with a new
macro name, as Jan suggested.

 -- Keir

Justin T. Gibbs

2012-Feb-27 15:22 UTC

head link

Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

I think there is more to cleanup here.  These drivers have their
own constant, MAX_SEGMENTS_PER_REQ.  If this is the real driver
limit, it should be used consistently everywhere, but also tied to
blkif.h via a MIN() instead of directly hardcoded to 11.

I''m working on patches for this and the other isues within the
xen-unstable tree now, and will submit them for review once I
think they are ready.

--
Justin

On Feb 27, 2012, at 2:43 AM, Ian Campbell wrote:
> On Mon, 2012-02-27 at 09:32 +0000, Ian Campbell wrote:
>>> The same would go for tools/blktap*/.
>> 
>> That one never occurred to me, even after I grepped for the symbol.
> 
> I guess the following ought to fix it...
> 
> 8<---------------------------------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1330335804 0
> # Node ID 42978617757ff3c8fce5c6d1873ad86d46c594ae
> # Parent  0bb45a06c1a8b049dba322cfb91c86c253068f0e
> blktap: Fix after blkif.h update
> 
> 24875:a59c1dcfe968 made an incompatible change to the interface headers
which
> needs to be reflected here Fix after blkif.h update
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap/lib/blktaplib.h
> --- a/tools/blktap/lib/blktaplib.h	Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap/lib/blktaplib.h	Mon Feb 27 09:43:24 2012 +0000
> @@ -230,10 +230,10 @@ int setup_probe_watch(struct xs_handle *
> 
> /* Accessing attached data page mappings */
> #define MMAP_PAGES                                              \
> -    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
> +    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
> #define MMAP_VADDR(_vstart,_req,_seg)                                   \
>     ((_vstart) +                                              \
> -     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +    \
> +     ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) +    \
>      ((_seg) * getpagesize()))
> 
> 
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-diff.c
> --- a/tools/blktap2/drivers/tapdisk-diff.c	Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap2/drivers/tapdisk-diff.c	Mon Feb 27 09:43:24 2012 +0000
> @@ -429,7 +429,7 @@ tapdisk_stream_enqueue1(void)
> 		breq->sector_number = sreq->sec;
> 		breq->operation     = BLKIF_OP_READ;
> 
> -		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
> +		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
> 			uint32_t secs;
> 			struct blkif_request_segment *seg = breq->seg + i;
> 
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-stream.c
> --- a/tools/blktap2/drivers/tapdisk-stream.c	Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap2/drivers/tapdisk-stream.c	Mon Feb 27 09:43:24 2012 +0000
> @@ -296,7 +296,7 @@ tapdisk_stream_enqueue(event_id_t id, ch
> 		breq->sector_number = sreq->sec;
> 		breq->operation     = BLKIF_OP_READ;
> kk
> -		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
> +		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
> 			uint32_t secs = MIN(s->end - s->cur, psize >> SECTOR_SHIFT);
> 			struct blkif_request_segment *seg = breq->seg + i;
> 
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/include/blktaplib.h
> --- a/tools/blktap2/include/blktaplib.h	Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap2/include/blktaplib.h	Mon Feb 27 09:43:24 2012 +0000
> @@ -222,10 +222,10 @@ typedef struct msg_lock {
> 
> /* Accessing attached data page mappings */
> #define MMAP_PAGES                                                    \
> -    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
> +    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
> #define MMAP_VADDR(_vstart,_req,_seg)                                 \
>     ((_vstart) +                                                      \
> -     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +      \
> +     ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) +     
\
>      ((_seg) * getpagesize()))
> 
> /* Defines that are only used by library clients */
> 
>

Seemingly Similar Threads

Search for more seemingly similar threads

Xen devel - Feb 2012 - [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

[xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

[PATCH qemu-xen-traditional] Fix after blkif.h update

[PATCH qemu-xen] Fix after blkif.h update

Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

Re: [PATCH qemu-xen-traditional] Fix after blkif.h update

Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd

Seemingly Similar Threads