From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wi19P-00075t-8H for qemu-devel@nongnu.org; Wed, 07 May 2014 08:40:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wi19F-0005JS-LZ for qemu-devel@nongnu.org; Wed, 07 May 2014 08:40:43 -0400 Received: from e06smtp14.uk.ibm.com ([195.75.94.110]:60140) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wi19F-0005Hz-Bu for qemu-devel@nongnu.org; Wed, 07 May 2014 08:40:33 -0400 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 May 2014 13:40:32 +0100 Date: Wed, 7 May 2014 14:40:23 +0200 From: Greg Kurz Message-ID: <20140507144023.690673b0@bahia.local> In-Reply-To: <536A1EFC.4060405@suse.de> References: <20140505074816.25523.71374.stgit@bahia.local> <20140505080520.25523.44406.stgit@bahia.local> <20140507101443.146fc26d@bahia.local> <5369F864.7040406@suse.de> <8EFC6697-F364-41B3-9097-ED5529292105@suse.de> <20140507121924.3503e110@bahia.local> <536A1EFC.4060405@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 3/4] target-ppc: ppc can be either endian List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , Marc Zyngier , Rusty Russell , QEMU Developers , "qemu-ppc@nongnu.org" , "bharata@linux.vnet.ibm.com" , Andreas =?UTF-8?B?RsOkcmJl?= =?UTF-8?B?cg==?= On Wed, 07 May 2014 13:54:36 +0200 Alexander Graf wrote: > On 05/07/2014 12:19 PM, Greg Kurz wrote: > > On Wed, 7 May 2014 11:41:10 +0200 > > Alexander Graf wrote: > > > >> > >>> Am 07.05.2014 um 11:26 schrieb Peter Maydell : > >>> > >>>> On 7 May 2014 10:09, Alexander Graf wrote: > >>>> I don't think we should overengineer hacks for legacy virtio. > >>> Agreed. So what's our final conclusion: virtio endianness > >>> is the endianness of the guest kernel at the point where > >>> it triggers a reset of the virtio device, yes? > >> I just realized we're talking about virtio in a non-virtio thread. This patch set is about core dump support which is different from virtio bi-endian support. While both may end up at the same logic, I don't like the idea to mix them. This function is PPC internal. > >> > >> Alex > >> > > Correct and now I have this feeling about using LPCR_ILE versus MSR_LE... > > > > LPCR_ILE reflects the interrupt vector endianness. It is set during early boot > > by the guest kernel according to the desired endianness. MSR_LE gives the > > current endian mode for the cpu. > > > > The idea is that you need to rely on LPCR_ILE when you peek from the host > > because you lack context and MSR_LE may be have been temporarily changed. > > This is clearly the case for dump support. > > > > Now when it comes to virtio, we cache the endianness at device reset time: MSR_LE from > > current_cpu should reflect the guest kernel endianness, no ? > > > > In this case we could end up like what's being currently discussed with ARM: > > > > http://www.spinics.net/lists/kvm-arm/msg09099.html > > http://www.spinics.net/lists/kvm-arm/msg09091.html > > > > Alex, > > > > If we agree that current_cpu->MSR_LE does the job when the guest kernel resets > > the device, then I guess we don't even need this patch... > > Either one works for me as long as we put it into a spec. No solution > will be able to fulfill all cases. > > The uglyness about the current_cpu bit is that devices are usually not > supposed to know about the cpu accesses come from usually. But then > again devices shouldn't know about the endianness of a cpu either so I > guess it's ok to breach layers here. > > Rusty, do you have strong feelings either way? > > > Alex > Coming back to the initial subject. What about changing the last sentence in the commit message to the following ? "And when it comes to dumping a guest, the information is needed to write ELF headers using the kernel endianness." This would make the patch a PPC64 dump only business and end the debate. :) Tell me if you want me to repost. Cheers. -- Gregory Kurz kurzgreg@fr.ibm.com gkurz@linux.vnet.ibm.com Software Engineer @ IBM/Meiosys http://www.ibm.com Tel +33 (0)562 165 496 "Anarchy is about taking complete responsibility for yourself." Alan Moore.