From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4utW-00024H-8z for qemu-devel@nongnu.org; Tue, 06 Mar 2012 08:57:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4utQ-0007bK-23 for qemu-devel@nongnu.org; Tue, 06 Mar 2012 08:57:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4utP-0007b6-QO for qemu-devel@nongnu.org; Tue, 06 Mar 2012 08:57:31 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q26DvUPp002099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Mar 2012 08:57:30 -0500 Message-ID: <4F5617C6.9020107@redhat.com> Date: Tue, 06 Mar 2012 14:57:26 +0100 From: Paolo Bonzini 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> In-Reply-To: <20120306133331.GB12096@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: "Michael S. Tsirkin" Cc: amit.shah@redhat.com, uobergfe@redhat.com, owasserm@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com 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). 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