[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] KVM and variable-endianness guest CPUs
From: |
Christoffer Dall |
Subject: |
Re: [Qemu-ppc] KVM and variable-endianness guest CPUs |
Date: |
Mon, 27 Jan 2014 16:40:15 -0800 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Jan 28, 2014 at 11:32:41AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2014-01-23 at 20:11 -0800, Victor Kamensky wrote:
> > > I would take 50 byteswaps with a clear ABI any day over an obscure
> > > standard that can avoid a single hardware-on-register instruction.
> > This
> > > is about designing a clean software interface, not about building an
> > > optimized integrated stack.
> > >
> > > Unfortunately, this is going nowhere, so I think we need to stop
> > this
> > > thread. As you can see I have sent a patch as a clarification to
> > the
> > > ABI, if it's merged we can move on with more important tasks.
> >
> > OK, that is fine. I still believe is not the best choice,
> > but I agree that we need to move on. I will respin my
> > V7 KVM BE patches according to this new semantics, I will
> > integrate comments that you (thanks!) and others gave me
> > over mailing list and post my series again when it is ready.
>
> Right, the whole "host endian" is a horrible choice from every way you
> look at it, but I'm afraid it's unfixable since it's already ABI :-(
>
Why is it a horrible choice?
I don't think it's actually ABI at this point, it's undefined.
The only thing fixed is PPC BE host and ARM LE host, and in both cases
we currently perform a byteswap in KVM if the guest is a different
endianness.
Honestly I don't care which way it's defined, as long as it's defined
somehow, and I have not yet seen anyone formulate how the ABI
specification should be worded, so people clearly understand what's
going on.
If you take a look at the v2 patch "KVM: Specify byte order for
KVM_EXIT_MMIO", that's where it ended up.
If you can formulate something with your experience in endianness that
makes this clear, it would be extremely helpful.
-Christoffer
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, (continued)
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Victor Kamensky, 2014/01/22
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Peter Maydell, 2014/01/23
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Victor Kamensky, 2014/01/23
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Peter Maydell, 2014/01/23
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Victor Kamensky, 2014/01/23
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Christoffer Dall, 2014/01/23
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Victor Kamensky, 2014/01/23
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Christoffer Dall, 2014/01/23
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Victor Kamensky, 2014/01/23
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Benjamin Herrenschmidt, 2014/01/27
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs,
Christoffer Dall <=
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Benjamin Herrenschmidt, 2014/01/27
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Victor Kamensky, 2014/01/23
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Benjamin Herrenschmidt, 2014/01/27
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Benjamin Herrenschmidt, 2014/01/27
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Benjamin Herrenschmidt, 2014/01/27
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Peter Maydell, 2014/01/27
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Benjamin Herrenschmidt, 2014/01/27
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Christoffer Dall, 2014/01/27
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Benjamin Herrenschmidt, 2014/01/27
- Re: [Qemu-ppc] KVM and variable-endianness guest CPUs, Christoffer Dall, 2014/01/28