From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antoine Martin Subject: Re: raw disks no longer work in latest kvm (kvm-88 was fine) Date: Mon, 08 Mar 2010 01:01:18 +0700 Message-ID: <4B93E9EE.6020701@nagafix.co.uk> References: <4B92BF97.4040001@nagafix.co.uk> <4B92C90B.4030807@msgid.tls.msk.ru> <4B932829.8090503@nagafix.co.uk> <4B9372B6.3050408@msgid.tls.msk.ru> <20100307100022.GA23201@infradead.org> <4B93A624.8010707@nagafix.co.uk> <4B93AF8A.3070805@nagafix.co.uk> <4B93C2F9.7030904@msgid.tls.msk.ru> <4B93DE3F.4090103@nagafix.co.uk> <4B93DFF0.5050905@redhat.com> <20100307172151.GA24859@infradead.org> <4B93E29E.6090609@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , Michael Tokarev , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mamba.nagafix.co.uk ([194.145.196.68]:34926 "EHLO mail.nagafix.co.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754528Ab0CGSBZ (ORCPT ); Sun, 7 Mar 2010 13:01:25 -0500 In-Reply-To: <4B93E29E.6090609@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/08/2010 12:30 AM, Avi Kivity wrote: > On 03/07/2010 07:21 PM, Christoph Hellwig wrote: >> On Sun, Mar 07, 2010 at 07:18:40PM +0200, Avi Kivity wrote: >>>> The only things that stands out is this before the "read failed" >>>> message: >>>> [pid 9098] lseek(12, 0, SEEK_END) = 1321851815424 >>>> [pid 9121] pread(12, 0x7fa50a0e47d0, 2048, 0) = -1 EINVAL (Invalid >>>> argument) >>>> >>> The buffer is unaligned here, yet the file was opened with O_DIRECT >>> (cache=none). This is strange, since alignment is not related to disk >>> size. Yes cache=none: "-drive file=./vm/var_fs,if=virtio,cache=none" Side question: this is the right thing to do for raw partitions, right? >> The other interesting thing is that it's using pread - which means >> it's a too old kernel to use preadv and thus a not very well tested >> codepath with current qemu. Too old?, I am confused: both host and guest kernels are 2.6.33! I built KVM against the 2.6.30 headers though. > > It may also be that glibc is emulating preadv, incorrectly. Not sure how to do that. > > Antoine, can you check this? ltrace may help, This the only part that looked slightly relevant: [pid 26883] __xstat64(1, "./vm/media_fs", 0x7fff92e40500) = 0 [pid 26883] malloc(48) = 0x2a38d60 [pid 26883] memset(0x2a38d60, '\000', 48) = 0x2a38d60 [pid 26883] open64("./vm/media_fs", 540674, 00) = 12 [pid 26883] posix_memalign(0x7fff92e40560, 512, 16384, -1, 48) = 0 [pid 26883] lseek64(12, 0, 2, 0x7f404f2f3e60, 4) = 0x133c4820600 > or run 'strings libc.so | grep pread'. > strings /lib/libc.so.6 | grep pread preadv preadv64 pread __pread64_chk __pread64 __pread_chk Antoine