Re: [Xen-devel] [Qemu-devel] use O_DIRECT to open disk images for IDE failed under xen-4.1.2 and qemu upstream

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 24 May 2013, Gonglei (Arei) wrote:
> Hi,
> 
> > 
> > On Thu, 23 May 2013, Gonglei (Arei) wrote:
> > > Hi, all
> > >
> > > I use O_DIRECT to open disk images for IDE, but I'm failed. After debug, 
> > > I get
> > the below logs:
> > > [2013-05-22 23:25:46] ide: CMD=c8
> > > [2013-05-22 23:25:46] bmdma: readb 0x00 : 0x08
> > > [2013-05-22 23:25:46] bmdma: writeb 0x00 : 0x09
> > > [2013-05-22 23:25:46] bmdma_cmd_writeb: 0x00000009
> > > [2013-05-22 23:25:46] bmdma: readb 0x02 : 0x01
> > > [2013-05-22 23:25:46] bmdma: readb 0x02 : 0x01
> > > [2013-05-22 23:25:46] bmdma: readb 0x02 : 0x01
> > > [2013-05-22 23:25:46] bmdma: readb 0x02 : 0x01
> > > [2013-05-22 23:25:46] bmdma: readb 0x02 : 0x01
> > > [2013-05-22 23:25:46] bmdma: readb 0x02 : 0x01
> > > [2013-05-22 23:26:39] bmdma: writeb 0x00 : 0x08
> > > [2013-05-22 23:26:39] bmdma_cmd_writeb: 0x00000008
> > > [2013-05-22 23:26:56] ====== offset:0 buf:0x7ff100f21c00 count:512
> > aio_offset:0
> > > [2013-05-22 23:31:30] ====== offset:0 buf:0x7ff100f21c00 count:512
> > aio_offset:0
> > > [2013-05-22 23:31:30] ====== handle_aiocb_rw_linear errno: -14
> > > [2013-05-22 23:31:30] ====== paio_complete errno=14
> > > [2013-05-22 23:31:30] ====== ide_dma_error!!!
> > > [2013-05-22 23:31:30] ide: read status addr=0x3f6 val=41
> > >
> > > QEMU command line :
> > > qemu-system-i386 -xen-domid 837 -chardev
> > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-837,server,nowait -mon
> > chardev=libxl-cmd,mode=control -name suse11 -vnc 0.0.0.0:1 -serial pty -boot
> > order=c -usb -usbdevice tablet -smp 2,maxcpus=2 -device
> > rtl8139,id=nic0,netdev=net0,mac=00:16:3e:13:d3:72 -netdev
> > type=tap,id=net0,ifname=tap837.0,downscript=no -M xenfv -m 2040 -drive
> > file=/mnt/sdd/image/suse.image,if=ide,index=0,media=disk,format=raw,cache
> > =none
> > >
> > > errno 14 shows Bad Address. And I find QEMU_AIO_MISALIGNED flag bit is
> > not set through debug.
> > >
> > >     /*
> > >      * If O_DIRECT is used the buffer needs to be aligned on a sector
> > >      * boundary.  Check if this is the case or tell the low-level
> > >      * driver that it needs to copy the buffer.
> > >      */
> > >     if ((bs->open_flags & BDRV_O_NOCACHE)) {
> > >         if (!bdrv_qiov_is_aligned(bs, qiov)) {    //if the address is
> > aligned-512, will no meet the conditions
> > >             type |= QEMU_AIO_MISALIGNED;
> > > #ifdef CONFIG_LINUX_AIO
> > >         } else if (s->use_aio) {
> > >             return laio_submit(bs, s->aio_ctx, s->fd, sector_num, qiov,
> > >                                nb_sectors, cb, opaque, type);
> > > #endif
> > >
> > > Next process:
> > > static ssize_t handle_aiocb_rw(struct qemu_paiocb *aiocb)
> > > {
> > >     ssize_t nbytes;
> > >     char *buf;
> > >
> > >     if (!(aiocb->aio_type & QEMU_AIO_MISALIGNED)) {
> > >         /*
> > >          * If there is just a single buffer, and it is properly aligned
> > >          * we can just use plain pread/pwrite without any problems.
> > >          */
> > >         if (aiocb->aio_niov == 1)
> > >              return handle_aiocb_rw_linear(aiocb,
> > aiocb->aio_iov->iov_base); //this way, and reports errno 14 next
> > >
> > > Anyone have a good method to resolve this bug? Thanks!
> > 
> > I know that this is not the answer you are looking for but why do you
> > want to use O_DIRECT with IDE?
> > It should be perfectly safe to use write-back.
> 
> A few days ago, I asked a question about the IDE FLUSH time of guestï 
> http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg02642.html
> 
> finally I found that because Qemu use write-back flag to open disk images by 
> default. 
> so I hope to use O_DIRECT to avoid meeting that problem, but I'm failed under 
> Xen platform with Qemu upstream.
 
I don't think that switching opening flags is the right way to approach
this issue.

Reading back your original email, it seems reasonable to me to return
BSY to the guest.

Probably nobody has seen this problem before because fdatasync is not
usually that slow.  I imagine the your bug could be reproduced by
replacing the call to fdatasync with a sleep?

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