From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnPI3-0001Ai-Mu for qemu-devel@nongnu.org; Wed, 29 Apr 2015 06:32:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YnPI0-0000En-DR for qemu-devel@nongnu.org; Wed, 29 Apr 2015 06:32:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnPI0-0000EK-6Y for qemu-devel@nongnu.org; Wed, 29 Apr 2015 06:32:24 -0400 Date: Wed, 29 Apr 2015 12:32:04 +0200 From: "Michael S. Tsirkin" Message-ID: <20150429103204.GA12976@redhat.com> 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> <554093B3.2080205@de.ibm.com> <20150429105215.0a1122f2.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150429105215.0a1122f2.cornelia.huck@de.ibm.com> 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: Cornelia Huck Cc: Peter Maydell , hangaohuai@huawei.com, QEMU Developers , "Huangpeng (Peter)" , Christian Borntraeger , Shannon Zhao , Shannon Zhao , Paolo Bonzini , Christoffer Dall On Wed, Apr 29, 2015 at 10:52:15AM +0200, Cornelia Huck wrote: > On Wed, 29 Apr 2015 10:17:55 +0200 > Christian Borntraeger wrote: > > > 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 > > And (surprise, surprise) virtio-blk now works - but it also works when > I back out the atomic.h change again. No barrier problems :) > > Good news is that we can change s390-virtio to be just like the other > transports. Although I'd like to understand why it was broken before. > Maybe a guest change? Or a compiler change? Try compiling some old release, see what happens. Anyway, let's move DEFINE_VIRTIO_COMMON_FEATURES into the base class now. Can you send a patch pls? -- MST