Re: [Xen-devel] [PATCH 0 of 4] aio event fd support to blktap2

["David P. Quigley" <dpquigl@xxxxxxxxxxxxx>]

On Tue, 2010-02-02 at 15:57 -0800, Daniel Stodden wrote:
> On Tue, 2010-02-02 at 18:23 -0500, David P. Quigley wrote:
> > On Tue, 2010-02-02 at 15:10 -0800, Daniel Stodden wrote:
> > > On Tue, 2010-02-02 at 17:53 -0500, David P. Quigley wrote:
> > > > Is this patch set related to the AIO poll support that blocktap2 keeps
> > > > complaining about when I use tap:tapdisk:aio as the disk type? 
> > > 
> > > On pvops, yes.
> > > 
> > > > I found
> > > > the code that changes io_setup in the Novell Xen patches but its part of
> > > > a reasonably large patch.
> > > 
> > > Shouldn't depend on the disktype. As long as it's blktap, not blkback on
> > > a raw vdi, all disk drivers depend on this.
> > > 
> > > The io_setup change you're referring might rather be the old way of
> > > doing things. It made io_setup return an fd to poll, if the io_setup
> > > caller calls with a 'magic' (1, actually) aio_ctx value.
> > > 
> > > Daniel
> > > 
> > 
> > Seems like I made a mistake and copied the version of the error that was
> > generated before I updated xen-unstable to have your latest changes. Now
> > I'm getting a completely different error. Does the aio driver handle raw
> > disk files or do I need to create the image in some special way? Not the
> > error I get has to do with incorrect magic in the shared info and this
> > results in a segfault. I'll try to hunt them down. The tapdisk output is
> > listed below.
> > 
> > Dave
> > 
> > tapdisk2[2366]: Created /dev/xen/blktap-2/blktap0 device
> > tapdisk2[2366]: Created /dev/xen/blktap-2/tapdev0 device
> > tapdisk2[2366]: new interface: ring: 251, device: 253, minor: 0
> > tapdisk2[2366]: I/O queue driver: lio
> > tapdisk2[2366]: Incorrect magic in shared info.
> > tapdisk2[2366]: Failed to open shared info.
> > tapdisk2[2366]: segfault at 18 ip 0000003e42008dc1 sp 00007fffd29889a0 
> > error 4 in libpthread-2.10.2.so[3e42000000+17000]
> 
> Please try disabling -DMEMSHR in the Makefile.
> 
> [Assuming that helps: Keir, I think there is help underway, but should
> we turn it off by default in the meantime?]
> 
> Is this on the pvops kernel?
> 
> - Make sure it doesn't have HIGHPTE set.
> - Apply the bunch of kernel patches posted. ("blktap2 on pvops updates")
>   I don't think they made it into Jeremy's tree yet.
> 
> Let me know if there's more trouble, we're presently preparing another
> bunch of updates, so the time is just right :)
> 
> Daniel

So I'm applying the patches and building now so I haven't have any
trouble yet but you have a small issue with your 4th patch in the series
you posted late last week. I actually looked into making blktap2 compile
as a module and I ran into the two symbols you exported. I don't see a
way around exporting zap_page_range however mm_init isn't supposed to be
used anymore. If you look in Documentation/vm/active_mm.txt there is
this text below.

[Start Quote]
Also, a new rule is that _nobody_ ever has "init_mm" as a real MM any
more. "init_mm" should be considered just a "lazy context when no other
context is available", and in fact it is mainly used just at bootup when
no real VM has yet been created. So code that used to check

        if (current->mm == &init_mm)

should generally just do

        if (!current->mm)

instead (which makes more sense anyway - the test is basically one of
"do we have a user context", and is generally done by the page fault
handler and things like that).

[End Quote]

I'm not sure if you really don't have a real context at that point but I
found it weird that init_mm was being used when this documentation seems
to indicate no one should really be using it.

Dave


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel