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
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
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);
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
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
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
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
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
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
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 */ > >