From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wv2hz-000806-OH for qemu-devel@nongnu.org; Thu, 12 Jun 2014 06:58:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wv2hr-0007Ht-BL for qemu-devel@nongnu.org; Thu, 12 Jun 2014 06:58:15 -0400 Received: from cantor2.suse.de ([195.135.220.15]:59779 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wv2hr-0007Hc-0K for qemu-devel@nongnu.org; Thu, 12 Jun 2014 06:58:07 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexander Graf In-Reply-To: <20140612125056.0c5c5dca@bahia.local> Date: Thu, 12 Jun 2014 12:58:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <742C1ED7-B058-4AE8-9E44-3D3AAAB369BB@suse.de> References: <20140514154130.10746.1412.stgit@bahia.local> <20140514154230.10746.56297.stgit@bahia.local> <5384A8D2.8050104@redhat.com> <20140529111253.4ff55199@bahia.local> <538708FA.4070309@redhat.com> <20140612094351.6295fd38@bahia.local> <53996B0E.4040808@redhat.com> <20140612110601.3fe5626e@bahia.local> <539970B3.3040304@redhat.com> <20140612093712.GA22565@redhat.com> <5399755E.10902@redhat.com> <53997638.6020403@suse.de> <20140612121440.6ce62e77@bahia.local> <20140612125056.0c5c5dca@bahia.local> Subject: Re: [Qemu-devel] [PATCH RFC 8/8] virtio: add endian-ambivalent support to VirtIODevice List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Greg Kurz Cc: Kevin Wolf , Fam Zheng , Anthony Liguori , Juan Quintela , "Michael S. Tsirkin" , "qemu-devel@nongnu.org" , Stefan Hajnoczi , Amit Shah , Paolo Bonzini , =?utf-8?Q?Andreas_F=C3=A4rber?= > Am 12.06.2014 um 12:50 schrieb Greg Kurz : >=20 > On Thu, 12 Jun 2014 12:39:27 +0200 > Alexander Graf wrote: >=20 >>=20 >>=20 >>> Am 12.06.2014 um 12:14 schrieb Greg Kurz : >>>=20 >>> On Thu, 12 Jun 2014 11:43:20 +0200 >>> Alexander Graf wrote: >>>=20 >>>>=20 >>>>>> On 12.06.14 11:39, Paolo Bonzini wrote: >>>>>> Il 12/06/2014 11:37, Michael S. Tsirkin ha scritto: >>>>>> Maybe just drop unnecessary stuff for new machine types? >>>>>> Then we won't need hacks to migrate it. >>>>>=20 >>>>> For any machine type it's trivial to migrate it. All machine types=20= >>>>> including old ones can disregard the migrated values. >>>>=20 >>>> How about a patch like this before the actual LE awareness ones? With=20= >>>> this we should make virtio-serial config space completely independent o= f=20 >>>> live migration. >>>>=20 >>>> Also since QEMU versions that do read these swapped values during=20 >>>> migration are not bi-endian aware, we can never get into a case where a= =20 >>>> cross-endian save needs to be considered ;). >>>>=20 >>>>=20 >>>> Alex >>>>=20 >>>>=20 >>>> diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c >>>> index 2b647b6..73cb9b7 100644 >>>> --- a/hw/char/virtio-serial-bus.c >>>> +++ b/hw/char/virtio-serial-bus.c >>>> @@ -670,6 +670,7 @@ static int virtio_serial_load(QEMUFile *f, void=20 >>>> *opaque, int version_id) >>>> uint32_t max_nr_ports, nr_active_ports, ports_map; >>>> unsigned int i; >>>> int ret; >>>> + uint32_t tmp; >>>>=20 >>>> if (version_id > 3) { >>>> return -EINVAL; >>>> @@ -685,17 +686,12 @@ static int virtio_serial_load(QEMUFile *f, void=20= >>>> *opaque, int version_id) >>>> return 0; >>>> } >>>>=20 >>>> - /* The config space */ >>>> - qemu_get_be16s(f, &s->config.cols); >>>> - qemu_get_be16s(f, &s->config.rows); >>>> - >>>> - qemu_get_be32s(f, &max_nr_ports); >>>> - tswap32s(&max_nr_ports); >>>> - if (max_nr_ports > tswap32(s->config.max_nr_ports)) { >>>> - /* Source could have had more ports than us. Fail migration. *= / >>>> - return -EINVAL; >>>> - } >>>> + /* Unused */ >>>> + qemu_get_be16s(f, &tmp); >>>> + qemu_get_be16s(f, &tmp); >>>> + qemu_get_be32s(f, &tmp); >>>>=20 >>>> + max_nr_ports =3D tswap32(s->config.max_nr_ports); >>>> for (i =3D 0; i < (max_nr_ports + 31) / 32; i++) { >>>> qemu_get_be32s(f, &ports_map); >>>=20 >>> For the moment, we have 0 < max_nr_ports < 32 so the source >>> machine only stores a single 32 bit value... If this limit >>> gets raised, we can end up sending more than that... and >>> only the source machine max_nr_ports value can give the >>> information... >>=20 >> Why? This value only ever gets set in realize, so it will not change duri= ng the lifetime of the device - which means we don't need to migrate it. >=20 > I agree with the fact that the value does not change and should not be mig= rated in the first place. > I am just worried about the size of the active ports bitmap that is stream= ed in the for loop... it > is only 32 bit as of today, because we are limited to 32 ports. How would t= his work if the limit is > raised ? How can the destination machine know how many bits have to be rea= d ? The destination has be be executed in compat mode to the older qemu version v= ia a versioned machine type. This should ensure that limits are kept. Alex