From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [PATCH seabios 3/3] kvmtool: support larger virtio queues Date: Fri, 03 Nov 2017 16:34:26 +0100 Message-ID: <1509723266.5662.5.camel@redhat.com> References: <20171102155031.17454-1-kraxel@redhat.com> <20171102155031.17454-4-kraxel@redhat.com> <66585b58-481f-7eb2-1786-43e377619368@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: James Morse To: Jean-Philippe Brucker , "seabios@seabios.org" , "kvm@vger.kernel.org" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:51180 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756013AbdKCPe3 (ORCPT ); Fri, 3 Nov 2017 11:34:29 -0400 In-Reply-To: <66585b58-481f-7eb2-1786-43e377619368@arm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, 2017-11-03 at 13:49 +0000, Jean-Philippe Brucker wrote: > On 02/11/17 15:50, Gerd Hoffmann wrote: > > Queues have 256 entries on kvmtool, support that.  Needs more > > memory for > > virtqueues now.  But with the move to 32bit drivers for virtio this > > should not be much of an issue any more. > > > > Known problems (probably kvmtool bugs): > >  * Must bump to 260 entries to make things actually work, > >    otherwise kvmtool segfaults.  Oops. > > You mean setting MAX_QUEUE_NUM to 256 instead of 260 in seabios > causes a > kvmtool crash? yes. > Do you have any more detail on the segfault? Ok, lets have a look with gdb ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f81caf3c700 (LWP 20234)] virt_queue__get_head_iov (vq=vq@entry=0x7f82576be0a0, iov=iov@entry=0x7 f826770aae0,      out=out@entry=0x7f826770bae0, in=in@entry=0x7f826770bae2, head=65104, kvm=kvm@entry=0x246eee0)     at virtio/core.c:105 105             *out = *in = 0; (gdb) bt #0  0x000000000040c91b in virt_queue__get_head_iov (vq=vq@entry=0x7f825 76be0a0, iov=iov@entry=0x7f826770aae0, out=out@entry=0x7f826770bae0, in =in@entry=0x7f826770bae2, head=65104, kvm=kvm@entry=0x246eee0) at virtio/core.c:105 #1  0x000000000040bbf7 in virtio_blk_thread (bdev=0x7f82576be010, vq=0x7f82576be0a0, kvm=0x246eee0)     at virtio/blk.c:134 #2  0x000000000040bbf7 in virtio_blk_thread (dev=0x7f82576be010) at virtio/blk.c:208 #3  0x00007f82571c6e25 in start_thread () at /lib64/libpthread.so.0 #4  0x00007f82543b134d in clone () at /lib64/libc.so.6 (gdb) print *vq $1 = {vring = {num = 256, desc = 0x7f824cf3e000, avail = 0x7f824cf3f000, used = 0x7f824cf40000},    pfn = 524285, last_avail_idx = 263, last_used_signalled = 1, endian = 1} last_avail_idx looks bogus ... > Since seabios doesn't use the event indexes, this would lead to > missing signals, but not a segfault. seabios polls anyway, so it doesn't need signals. > >  * Linux kernel doesn't find virtio-blk devices after seabios > >    initialized them.  virtio device reset not working properly? > > No, reset isn't implemented at all... A lot of work is required to > properly clear the state and threads of each device. Hmm. That is required for any kind of boot loader support though. /me wonders what the kvmtool --firmware switch is good for then if a direct kernel boot is apparently the only thing which actually works. cheers, Gerd