From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39341) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xtzri-0007nS-HV for qemu-devel@nongnu.org; Thu, 27 Nov 2014 09:16:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xtzra-00008T-Bu for qemu-devel@nongnu.org; Thu, 27 Nov 2014 09:16:14 -0500 Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:53297) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xtzra-00007b-49 for qemu-devel@nongnu.org; Thu, 27 Nov 2014 09:16:06 -0500 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 27 Nov 2014 14:16:05 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 8F9D91B08049 for ; Thu, 27 Nov 2014 14:16:16 +0000 (GMT) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sAREG1bs21102716 for ; Thu, 27 Nov 2014 14:16:01 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sAREG0hM008371 for ; Thu, 27 Nov 2014 07:16:00 -0700 Date: Thu, 27 Nov 2014 15:15:55 +0100 From: Greg Kurz Message-ID: <20141127151555.450d3546@bahia.local> In-Reply-To: <20141127090842.GA3899@grmbl.mre> References: <1417067290-20715-1-git-send-email-david@gibson.dropbear.id.au> <20141127090842.GA3899@grmbl.mre> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Fix for crash after migration in virtio-rng on bi-endian targets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: quintela@redhat.com, rusty@rustcorp.com.au, qemu-devel@nongnu.org, agraf@suse.de, mst@redhat.com, pbonzini@redhat.com, David Gibson On Thu, 27 Nov 2014 14:38:42 +0530 Amit Shah wrote: > On (Thu) 27 Nov 2014 [16:48:10], David Gibson wrote: > > VirtIO devices now remember which endianness they're operating in in order > > to support targets which may have guests of either endianness, such as > > powerpc. This endianness state is transferred in a subsection of the > > virtio device's information. > > > > With virtio-rng this can lead to an abort after a loadvm hitting the > > assert() in virtio_is_big_endian(). This can be reproduced by doing a > > migrate and load from file on a bi-endian target with a virtio-rng device. > > The actual guest state isn't particularly important to triggering this. > > > > The cause is that virtio_rng_load_device() calls virtio_rng_process() which > > accesses the ring and thus needs the endianness. However, > > virtio_rng_process() is called via virtio_load() before it loads the > > subsections. Essentially the ->load callback in VirtioDeviceClass should > > only be used for actually reading the device state from the stream, not for > > post-load re-initialization. > > Agreed. > > > This patch fixes the bug by moving the virtio_rng_process() after the call > > to virtio_load(). Better yet would be to convert virtio to use vmsd and > > have the virtio_rng_process() as a post_load callback, but that's a bigger > > project for another day. > > I remember discussions on IRC last spring where I agreed I would work on it. :) > > This is bugfix, and should be considered for the 2.2 branch. > > This is undoing most of 3902d49e13c2428bd6381cfdf183103ca4477c1f , > added Greg to CC list. > This commit is indeed completely wrong: the load callback only makes sense when there's something to read which is obviously not the case here... This is definitely post load stuff :-\ Thanks ! :) Reviewed-by: Greg Kurz -- Greg > Did you try this on x86 guests, or with multiple rng devices? > > (keeping context for Greg) > > > Signed-off-by: David Gibson > > --- > > hw/virtio/virtio-rng.c | 15 ++++++++------- > > 1 file changed, 8 insertions(+), 7 deletions(-) > > > > diff --git a/hw/virtio/virtio-rng.c b/hw/virtio/virtio-rng.c > > index e85a979..473c044 100644 > > --- a/hw/virtio/virtio-rng.c > > +++ b/hw/virtio/virtio-rng.c > > @@ -113,20 +113,22 @@ static void virtio_rng_save(QEMUFile *f, void *opaque) > > > > static int virtio_rng_load(QEMUFile *f, void *opaque, int version_id) > > { > > + VirtIORNG *vrng = opaque; > > + int ret; > > + > > if (version_id != 1) { > > return -EINVAL; > > } > > - return virtio_load(VIRTIO_DEVICE(opaque), f, version_id); > > -} > > + ret = virtio_load(VIRTIO_DEVICE(vrng), f, version_id); > > + if (ret != 0) { > > + return ret; > > + } > > > > -static int virtio_rng_load_device(VirtIODevice *vdev, QEMUFile *f, > > - int version_id) > > -{ > > /* We may have an element ready but couldn't process it due to a quota > > * limit. Make sure to try again after live migration when the quota may > > * have been reset. > > */ > > - virtio_rng_process(VIRTIO_RNG(vdev)); > > + virtio_rng_process(vrng); > > > > return 0; > > } > > @@ -231,7 +233,6 @@ static void virtio_rng_class_init(ObjectClass *klass, void *data) > > vdc->realize = virtio_rng_device_realize; > > vdc->unrealize = virtio_rng_device_unrealize; > > vdc->get_features = get_features; > > - vdc->load = virtio_rng_load_device; > > } > > > > static void virtio_rng_initfn(Object *obj) > > > Thanks, > > Amit >