From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHlmf-0006qR-US for qemu-devel@nongnu.org; Thu, 05 Sep 2013 22:28:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHlmf-0001sw-3U for qemu-devel@nongnu.org; Thu, 05 Sep 2013 22:28:29 -0400 Received: from ozlabs.org ([2402:b800:7003:1:1::1]:35142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHlme-0001sf-NM for qemu-devel@nongnu.org; Thu, 05 Sep 2013 22:28:29 -0400 From: Rusty Russell In-Reply-To: <1376299687.32100.159.camel@pasglop> References: <1376294363-4650-1-git-send-email-rusty@rustcorp.com.au> <1376294363-4650-2-git-send-email-rusty@rustcorp.com.au> <1376299687.32100.159.camel@pasglop> Date: Fri, 06 Sep 2013 11:57:55 +0930 Message-ID: <87r4d265w4.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 1/8] virtio_get_byteswap: function for endian-ambivalent targets using virtio. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Michael Neuling , qemu-devel@nongnu.org Benjamin Herrenschmidt writes: > On Mon, 2013-08-12 at 17:29 +0930, Rusty Russell wrote: >> virtio data structures are defined as "target endian", which assumes >> that's a fixed value. In fact, that actually means it's >> platform-specific. >> >> Hopefully the OASIS virtio 1.0 spec will fix this. Meanwhile, create >> a hook for little endian ppc. > > Ok, sorry if I missed a previous debate on that one but why do you do a > call-out to architecture specific stuff (that is not even inline) on > every access ? > > If we consider that virtio byte order is global, can't you make it a > global that is *set* by the architecture rather than *polled* by > virtio ? OK, so after some more offline discussion it turns out these patches won't really work reliably, since powerpc kvm doesn't reflect the register into qemu. Mikey N has promised me a KVM_GET_ONE_REG to get the register, and I'll rework on top of that: we will query that whenever a device is reset (which Linux does on every device init, so it captures the kexec case too). Cheers, Rusty.