From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48722) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wwrxs-00038R-0l for qemu-devel@nongnu.org; Tue, 17 Jun 2014 07:54:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wwrxj-0001K3-BE for qemu-devel@nongnu.org; Tue, 17 Jun 2014 07:54:11 -0400 Received: from gate.crashing.org ([63.228.1.57]:50549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wwrxj-0001Jp-1i for qemu-devel@nongnu.org; Tue, 17 Jun 2014 07:54:03 -0400 Message-ID: <1403006031.7661.150.camel@pasglop> From: Benjamin Herrenschmidt Date: Tue, 17 Jun 2014 21:53:51 +1000 In-Reply-To: <20140617134057.157e6acf@bahia.local> References: <1402974463.7661.102.camel@pasglop> <539FC6B9.6060003@redhat.com> <1402981184.7661.107.camel@pasglop> <539FD3F1.2010304@redhat.com> <53A007D3.2090604@ozlabs.ru> <20140617120044.3ae839fa@bahia.local> <1402999758.7661.129.camel@pasglop> <20140617134057.157e6acf@bahia.local> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Greg Kurz Cc: Peter Maydell , Alexey Kardashevskiy , "qemu-devel@nongnu.org" , Alexander Graf , Gerd Hoffmann , Paolo Bonzini On Tue, 2014-06-17 at 13:40 +0200, Greg Kurz wrote: > This conclusion was reached while discussing dump support where we > use LPCR_ILE, and I wanted to add a common helper to be used by > virtio. Please find the thread in the link below: > > https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg00415.html > > Can you elaborate on the "less sense" opinion please ? I can't fathom how the endianness of a specific CPU at the point of the reset makes any sense vs. the overall endianness of the system. But this is all very theorical, fact is they will always match on powerpc, so I don't care that much :) In any case, for VGA, the right long term approach is a register in the adapter. Though we might want to keep the trick of forcing it when a PAPR guest does the H_SET_MODE hcall for general compatibility with existing guests, after all it's a paravirt interface, we can have side effects like that.... Cheers, Ben.