On Wed, 7 May 2014 11:41:10 +0200 Alexander Graf <ag...@suse.de> wrote:
> > > > Am 07.05.2014 um 11:26 schrieb Peter Maydell <peter.mayd...@linaro.org>: > > > >> On 7 May 2014 10:09, Alexander Graf <ag...@suse.de> 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... -- Gregory Kurz kurzg...@fr.ibm.com gk...@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.
