From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54789) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnNC2-0008NK-Mp for qemu-devel@nongnu.org; Wed, 29 Apr 2015 04:18:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YnNBz-0001wO-DE for qemu-devel@nongnu.org; Wed, 29 Apr 2015 04:18:06 -0400 Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:47161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnNBz-0001wC-4A for qemu-devel@nongnu.org; Wed, 29 Apr 2015 04:18:03 -0400 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 29 Apr 2015 09:17:59 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 068CD219004D for ; Wed, 29 Apr 2015 09:17:40 +0100 (BST) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t3T8HvTo9765126 for ; Wed, 29 Apr 2015 08:17:57 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t3T8HuIK026714 for ; Wed, 29 Apr 2015 02:17:57 -0600 Message-ID: <554093B3.2080205@de.ibm.com> Date: Wed, 29 Apr 2015 10:17:55 +0200 From: Christian Borntraeger MIME-Version: 1.0 References: <1430221873-5788-1-git-send-email-shannon.zhao@linaro.org> <20150428151249-mutt-send-email-mst@redhat.com> <20150428152419.67bc77b1.cornelia.huck@de.ibm.com> <20150428160354-mutt-send-email-mst@redhat.com> <20150428201255-mutt-send-email-mst@redhat.com> <20150428203016-mutt-send-email-mst@redhat.com> In-Reply-To: <20150428203016-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 0/2] virtio: Move host features to backends List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , Cornelia Huck Cc: Peter Maydell , hangaohuai@huawei.com, "Huangpeng (Peter)" , QEMU Developers , Shannon Zhao , Shannon Zhao , Paolo Bonzini , Christoffer Dall Am 28.04.2015 um 20:32 schrieb Michael S. Tsirkin: > On Tue, Apr 28, 2015 at 08:14:44PM +0200, Michael S. Tsirkin wrote: >> On Tue, Apr 28, 2015 at 04:35:16PM +0200, Michael S. Tsirkin wrote: >>> On Tue, Apr 28, 2015 at 03:24:19PM +0200, Cornelia Huck wrote: >>>> On Tue, 28 Apr 2015 14:16:40 +0100 >>>> Peter Maydell wrote: >>>> >>>>> On 28 April 2015 at 14:13, Michael S. Tsirkin wrote: >>>>>> The patches look correct to me too, but I want s390 >>>>>> cleaned up so it does not include COMMON_FEATURES >>>>>> in 100 places, and I prefer merging it all together. >>>>> >>>>> It seems a bit harsh to ask Shannon to do s390 cleanup when >>>>> he doesn't have any access to s390 guests or test cases... >>>>> Making S390 put COMMON_FEATURES in the right places seems >>>>> to me like a separate bit of s390-specific cleanup. >>>> >>>> Yep, see my other reply... I'm not quite sure what's wrong with >>>> event_idx on virtio-blk for s390-virtio, or I would gladly make this >>>> consistent with the other transports. Any hints appreciated :) >>> >>> Is this still happening? >>> >>> It is possible that what was missing was >>> 92045d80badc43c9f95897aad675dc7ef17a3b3f >>> and/or >>> a281ebc11a6917fbc27e1a93bb5772cd14e241fc >>> >> >> Found this: >> http://thread.gmane.org/gmane.comp.emulators.qemu/280334/focus=280357 >> so it's unlikely: these commits are from 2012, you saw >> issues in 2014. >> >> We really need to fix it. virtio 1 work will be much easier if >> we can just move features into virtio dev. Yes, we have to understand why event_idx breaks for the s390-virtio transport. > > I'm beginning to suspect this is a wrong implementation of barriers. > Questions: > - which compiler to you use? > - can you pls disassemble code for smp_wmb smp_rmb and smp_mb? > They all must do br %r14 I think, and this is what > s390x-linux-gnu-gcc generated for me: > s390x-linux-gnu-gcc (GCC) 4.9.1 s390 has strong memory ordering. Reads are in order, writes are in order. bcr 14,0 or bcr 15,0 then only serialize the reads against the writes. So smp_rmb and smp_wmb can be implemented as no-ops like QEMU. If your change "fixes" the issue then we have a problem somewhere else