qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 3/4] target-ppc: ppc can be either endian


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH v3 3/4] target-ppc: ppc can be either endian
Date: Wed, 07 May 2014 13:54:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130910 Thunderbird/17.0.9

On 05/07/2014 12:19 PM, Greg Kurz wrote:
On Wed, 7 May 2014 11:41:10 +0200
Alexander Graf <address@hidden> wrote:


Am 07.05.2014 um 11:26 schrieb Peter Maydell <address@hidden>:

On 7 May 2014 10:09, Alexander Graf <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]