From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4vHr-0007r7-0u for qemu-devel@nongnu.org; Tue, 06 Mar 2012 09:22:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4vHf-0004JR-Gc for qemu-devel@nongnu.org; Tue, 06 Mar 2012 09:22:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4vHf-0004J1-8w for qemu-devel@nongnu.org; Tue, 06 Mar 2012 09:22:35 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q26EMXdE032379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Mar 2012 09:22:33 -0500 Message-ID: <4F561D8E.20105@redhat.com> Date: Tue, 06 Mar 2012 16:22:06 +0200 From: Orit Wasserman MIME-Version: 1.0 References: <1331036527-7651-1-git-send-email-pbonzini@redhat.com> <1331036527-7651-2-git-send-email-pbonzini@redhat.com> <20120306133331.GB12096@redhat.com> <4F5617C6.9020107@redhat.com> In-Reply-To: <4F5617C6.9020107@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/3] virtio: let devices be permissive on enabled features List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: amit.shah@redhat.com, armbru@redhat.com, uobergfe@redhat.com, qemu-devel@nongnu.org, "Michael S. Tsirkin" On 03/06/2012 03:57 PM, Paolo Bonzini wrote: > Il 06/03/2012 14:33, Michael S. Tsirkin ha scritto: >>>> virtio_load checks features that are enabled by the guest and >>>> blocks migration if they are not available in the destination >>>> host. However, in some cases we can let features through because >>>> we know that guests will be able to proceed even without it. >>>> >>>> Signed-off-by: Paolo Bonzini >> >> So why do we need these hacks? You are saying things >> work fine without this information. Then, >> why not just have the bit set in supported features always? > > Not sure what you mean. > > virtio-balloon works fine only because our implementation does not set > the bit. I found it just by inspection, but it's wrong. If QEMU > started setting VIRTIO_F_BALLOON_MUST_TELL_HOST, migration would fail to > a version that does not set it. > > virtio-blk is what prompted the patch and it is a real bug. Updating > libvirt on the destination causes the source's scsi=on to become > scsi=off on the destination. Then migration fails (it used to crash, > Orit fixed the crash, I'm fixing the rest). To be more accurate we don't crash but give an error message: "Features 0x100006d4 unsupported. Allowed features: 0x71000654" The migration succeeds (from the user point of view ) but the virtio-blk device is not working properly. I changed the code to fail the migration. Paolo patch fixes the migration. Orit However, a kernel update > can cause the same behavioral change can happen even if > VIRTIO_BLK_F_SCSI remains on, so it is not a good reason to fail migration. > > Paolo