qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Heinz Graalfs <graalfs@linux.vnet.ibm.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	jfrei@linux.vnet.ibm.com, qemu-devel@nongnu.org,
	Stefan Hajnoczi <stefanha@redhat.com>,
	agraf@suse.de
Subject: Re: [Qemu-devel] [PATCH/RFC] block: Ensure that block size constraints are considered
Date: Fri, 07 Dec 2012 21:26:03 +0100	[thread overview]
Message-ID: <1354911963.3635.4.camel@br8hfpp0.de.ibm.com> (raw)
In-Reply-To: <50AC9B96.9070908@redhat.com>

Hello Kevin,

I'm resending my answer as of Nov 23rd.

Is this still on your queue?

Heinz


On Wed, 2012-11-21 at 10:15 +0100, Kevin Wolf wrote:
> Am 21.11.2012 09:58, schrieb Christian Borntraeger:
> > From: Heinz Graalfs <graalfs@linux.vnet.ibm.com>
> > 
> > While testing IPL code (booting) for s390x we faced some problems
> > with cache=none on dasds (4k block size) on bdrv_preads with length
> > values != block size.
> > 
> > This patch makes sure that bdrv_pread and friends work fine with
> > unaligned access even with cache=none
> >    - propagate alignment value also into bs->file struct
> >    - modify the size in case of no cache to avoid EINVAL on
> >      pread() etc. (file was opened with O_DIRECT).
> > 
> > This patch seems to cure the problems.
> > 
> > CC: Kevin Wolf <kwolf@redhat.com>
> > CC: Stefan Hajnoczi <stefanha@redhat.com>
> > Signed-off-by: Heinz Graalfs <graalfs@linux.vnet.ibm.com>
> > Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> > ---
> >  block.c           |    3 +++
> >  block/raw-posix.c |    6 ++++++
> >  2 files changed, 9 insertions(+)
> > 
> > diff --git a/block.c b/block.c
> > index 854ebd6..f23c562 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -4242,6 +4242,9 @@ BlockDriverAIOCB *bdrv_aio_ioctl(BlockDriverState *bs,
> >  void bdrv_set_buffer_alignment(BlockDriverState *bs, int align)
> >  {
> >      bs->buffer_alignment = align;
> > +    if ((bs->open_flags & BDRV_O_NOCACHE)) {
> > +        bs->file->buffer_alignment = align;
> > +    }
> 
> Any reason to restrict this to BDRV_O_NOCACHE?


OK, can be removed

> There have been patches to change the BDRV_O_NOCACHE flag from the
> monitor, in which case bdrv_set_buffer_alignment() wouldn't be called
> anew and O_DIRECT requests start to fail again.

> >  }
> >  
> >  void *qemu_blockalign(BlockDriverState *bs, size_t size)
> > diff --git a/block/raw-posix.c b/block/raw-posix.c
> > index f2f0404..baebf1d 100644
> > --- a/block/raw-posix.c
> > +++ b/block/raw-posix.c
> > @@ -700,6 +700,12 @@ static BlockDriverAIOCB *paio_submit(BlockDriverState *bs, int fd,
> >      acb->aio_nbytes = nb_sectors * 512;
> >      acb->aio_offset = sector_num * 512;
> >  
> > +    /* O_DIRECT also requires an aligned length */
> > +    if (bs->open_flags & BDRV_O_NOCACHE) {
> > +        acb->aio_nbytes += acb->bs->buffer_alignment - 1;
> > +        acb->aio_nbytes &= ~(acb->bs->buffer_alignment - 1);
> > +    }
> 
> Modifying aio_nbytes, but not the iov looks wrong to me. This may work
> in the handle_aiocb_rw_linear() code path, but not with actual vectored I/O.

Current coding ensures that read IO buffers always seem to be aligned
correctly. Whereas read length values are not always appropriate for an
O_DIRECT scenario.

For a 2048 formatted disk I verified that

1. non vectored IO - the length needs to be adapted several times,
   which is accomplished now by the patch.

2. vectored IO - the qiov's total length is always a multiple of the
   logical block size 
      (which is also verified in virtio_blk_handle_read())
   The particular iov length fields are already correctly setup as a
   multiple of the logical block size when processed in
   virtio_blk_handle_request().

> 
> Kevin
> 

  parent reply	other threads:[~2012-12-07 20:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-21  8:58 [Qemu-devel] [PATCH/RFC] block: Ensure that block size constraints are considered Christian Borntraeger
2012-11-21  9:15 ` Kevin Wolf
2012-11-21 10:00   ` Christian Borntraeger
2012-11-21 11:24     ` Heinz Graalfs
2012-11-21 16:03   ` Paolo Bonzini
2012-11-22 12:03     ` Christian Borntraeger
2012-11-23 10:45   ` Heinz Graalfs
2012-12-07 20:26   ` Heinz Graalfs [this message]
2012-12-10  8:55     ` Kevin Wolf
2012-12-11  9:58       ` Heinz Graalfs
2012-12-11 10:30         ` Kevin Wolf
2012-12-11 13:53           ` Heinz Graalfs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1354911963.3635.4.camel@br8hfpp0.de.ibm.com \
    --to=graalfs@linux.vnet.ibm.com \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=jfrei@linux.vnet.ibm.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).