From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55913)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jasowang@redhat.com>) id 1a4fmB-0001bZ-Is
	for qemu-devel@nongnu.org; Thu, 03 Dec 2015 21:07:12 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jasowang@redhat.com>) id 1a4fm8-0004ae-BT
	for qemu-devel@nongnu.org; Thu, 03 Dec 2015 21:07:11 -0500
Received: from mx1.redhat.com ([209.132.183.28]:43295)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jasowang@redhat.com>) id 1a4fm8-0004a1-5r
	for qemu-devel@nongnu.org; Thu, 03 Dec 2015 21:07:08 -0500
References: <20151201111108.6dd85381.cornelia.huck@de.ibm.com>
	<20151201131040.046ab170.cornelia.huck@de.ibm.com>
	<20151201152153.1bb1f58f.cornelia.huck@de.ibm.com>
	<565E8781.5060700@redhat.com>
	<20151202111128.03f4f46d.cornelia.huck@de.ibm.com>
From: Jason Wang <jasowang@redhat.com>
Message-ID: <5660F542.8010309@redhat.com>
Date: Fri, 4 Dec 2015 10:06:58 +0800
MIME-Version: 1.0
In-Reply-To: <20151202111128.03f4f46d.cornelia.huck@de.ibm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [2.5 issue] virtio-1 in virtio-net and old vhost
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>, qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>



On 12/02/2015 06:11 PM, Cornelia Huck wrote:
> On Wed, 2 Dec 2015 13:54:09 +0800
> Jason Wang <jasowang@redhat.com> wrote:
>
>> I wonder instead of rolling back in post_plugged(), maybe we could just
>> delay the region setups to post_plugged(). 
> If this is the saner thing to do for pci, sure.
>
>> Or just call transport
>> specific device_plugged() after get_features() call in
>> virtio_bus_device_plugged(). 
> The problem is that the VERSION_1 bit is only added in the
> ->device_plugged() callbacks by the transport, so ->get_features() can
> only be called after that. We have a dependency in both directions :(

Ok.

>
>> And I'm not sure we need to handle
>> migration compatibility in this case.
> The thing we would need to care about is basically the host kernel on
> the target supporting less than the host kernel on the source. Do we
> care about that in other contexts right now?

The problem is for pci: without this patch, guest may always see modern
bar is "disable-modern=false". But with this patch, on an old kernel
that does not support VERSION_1, even "disable-modern=false" were
specified, guest can not see modern bar anymore. Looks like a guest
visible change.