Xen devel - Jan 2013 - printk calls in xen-blkback/blkback.c not appearing

Hello Xen community,

I am having some trouble debugging code in blkback.c.  Specifically, I
can''t get any printk() statements within this file to show up (which
makes me think the code is not being executed).  Originally, I just
had them in dispatch_rw_block_io() (where the submit_bio call is) but
I have been experimenting with other functions and can''t get them to
work anywhere.  I can verify that my domUs are writing to disk, so
they must be using some i/o interface and, as far as I am aware,
blkback.c:dispatch_rw_block_io():submit_bio() should be the bottleneck
here.

I am running a dom0 with Ubuntu 12.04 with kernel version 3.2.28 and
two domUs with sparse Ubuntu installs. The DomU''s are reading and
writing to the disk without issue, except that they seem to be doing
it through different channels than the ones I am tracing.

Does anyone have any suggestions why these statements might not be
showing up (I have bumped them up to KERN_EMERG to make sure it''s not
a loglevel thing), or not executing?  Is there a good way to verify
that the proper xen-blkback module is being used, or not?  Have I
correctly determined that blkback.c should be the bottleneck for all
domU i/o?

Any comments are appreciated,

With thanks,

-Misiu

On Tue, 2013-01-29 at 16:39 +0000, Misiu Godfrey wrote:
> I am running a dom0 with Ubuntu 12.04 with kernel version 3.2.28 and
> two domUs with sparse Ubuntu installs. 
blkback only supports raw block devices, so if by sparse images you mean
files in dom0 (raw sparse files, qcow, vhd etc) rather than block
devices (/dev/lvm/blah etc) then you are using some other backend and
not blkback, perhaps blktap or qdisk (part of qemu).

You can tell which by looking at the name of the backend directory in
xenstore.

Ian.

Pardon, when I said "sparse install" I was referring to the domU OS I
installed using debootstrap (Ubuntu running a 2.6.38-15-generic-pae
kernel).

The modifications I am working on relate to any hard drive disk
accesses from DomUs, not just raw ones. It seems, from your comments,
that I might have been mistaken in assuming that blkback was a common
interface for this.  Is there a common interface that all DomU disk
I/O requests need to pass through or am I better off modifying each
driver separately?

Thanks for your help,

-Misiu

On Tue, Jan 29, 2013 at 11:47 AM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:
> On Tue, 2013-01-29 at 16:39 +0000, Misiu Godfrey wrote:
>> I am running a dom0 with Ubuntu 12.04 with kernel version 3.2.28 and
>> two domUs with sparse Ubuntu installs.
>
> blkback only supports raw block devices, so if by sparse images you mean
> files in dom0 (raw sparse files, qcow, vhd etc) rather than block
> devices (/dev/lvm/blah etc) then you are using some other backend and
> not blkback, perhaps blktap or qdisk (part of qemu).
>
> You can tell which by looking at the name of the backend directory in
> xenstore.
>
> Ian.
>

Please don''t top post.

On Tue, 2013-01-29 at 19:09 +0000, Misiu Godfrey wrote:
> The modifications I am working on relate to any hard drive disk
> accesses from DomUs, not just raw ones. It seems, from your comments,
> that I might have been mistaken in assuming that blkback was a common
> interface for this.
I''m afraid not, there are several block backends with different feature
sets, blkback is just one.

When I said "raw" I was referring to the fact that the blkback backend
only operates on "raw" block devices in the dom0, this is transparent
to
the frontend. (I''m not sure what you mean by "raw" above but
it seems to
not be the same thing).
>   Is there a common interface that all DomU disk
> I/O requests need to pass through or am I better off modifying each
> driver separately?
You will need to modify whichever backend the particular domU disk is
actually using. There is no common interface other than the ring
protocol which all backends speak to the frontend.

Ian.