Peter Maydell peter.mayd...@linaro.org writes:
On 9 August 2013 08:35, Rusty Russell ru...@rustcorp.com.au wrote:
That's a lot of replumbing and indirect function calls for a fairly
obscure case. We certainly don't have a nice CPUState lying around in
virtio at the moment, for example.
Anthony Liguori anth...@codemonkey.ws writes:
Rusty Russell ru...@rustcorp.com.au writes:
(Qemu run under eatmydata to eliminate syncs)
FYI, cache=unsafe is equivalent to using eatmydata.
Ah, thanks!
I can reproduce this although I also see a larger standard deviation.
BEFORE:
MIN:
Benjamin Herrenschmidt b...@kernel.crashing.org writes:
This whole exercise should have nothing to do with the current endian
mode of the CPU. If for example you are running lx86 (the x86 emulator
IBM provides) which exploits MSR:LE on POWER7 to run x86 binaries in
userspace, you don't want
On Mon, 2013-08-12 at 09:58 +0930, Rusty Russell wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org writes:
This whole exercise should have nothing to do with the current endian
mode of the CPU. If for example you are running lx86 (the x86 emulator
IBM provides) which exploits MSR:LE on
Anthony Liguori anth...@codemonkey.ws writes:
I suspect this is a premature optimization. With a weak function called
directly in the accessors below, I suspect you would see no measurable
performance overhead compared to this approach.
It's all very predictable so the CPU should do a decent
Andreas Färber afaer...@suse.de writes:
Am 08.08.2013 15:31, schrieb Anthony Liguori:
Rusty Russell ru...@rustcorp.com.au writes:
We have a mechanism to do weak functions via stubs/. I think it would
be better to do cpu_get_byteswap() as a stub function and then overload
it in the ppc64
Andreas Färber afaer...@suse.de writes:
Am 08.08.2013 17:40, schrieb Anthony Liguori:
Andreas Färber afaer...@suse.de writes:
Am 08.08.2013 15:31, schrieb Anthony Liguori:
We have a mechanism to do weak functions via stubs/. I think it would
be better to do cpu_get_byteswap() as a stub
On 9 August 2013 08:35, Rusty Russell ru...@rustcorp.com.au wrote:
That's a lot of replumbing and indirect function calls for a fairly
obscure case. We certainly don't have a nice CPUState lying around in
virtio at the moment, for example.
Actually if you're in an IO routine you do: it will
On Fri, 2013-08-09 at 17:05 +0930, Rusty Russell wrote:
Exactly, just read it as is in ... Endian mode. On the CPUs I am more
familiar with (e.g., 970), this used to be controlled via an MSR bit,
970 didn't have an LE mode :-)
which as CPUPPCState::msr exists per CPUState. I did not check
On 9 August 2013 03:58, Rusty Russell ru...@rustcorp.com.au wrote:
Anthony Liguori anth...@codemonkey.ws writes:
The distinction is important in QEMU. ppc64 is still
TARGET_WORDS_BIGENDIAN. We still want most stl_phys to treat integers
as big endian. There's just this extra concept that CPU
Rusty Russell ru...@rustcorp.com.au writes:
Anthony Liguori anth...@codemonkey.ws writes:
I suspect this is a premature optimization. With a weak function called
directly in the accessors below, I suspect you would see no measurable
performance overhead compared to this approach.
It's all
Rusty Russell ru...@rustcorp.com.au writes:
Anthony Liguori anth...@codemonkey.ws writes:
Daniel P. Berrange berra...@redhat.com writes:
The distinction is important in QEMU. ppc64 is still
TARGET_WORDS_BIGENDIAN. We still want most stl_phys to treat integers
as big endian. There's just
Am 09.08.2013 09:00, schrieb Rusty Russell:
Andreas Färber afaer...@suse.de writes:
Am 08.08.2013 15:31, schrieb Anthony Liguori:
Rusty Russell ru...@rustcorp.com.au writes:
We have a mechanism to do weak functions via stubs/. I think it would
be better to do cpu_get_byteswap() as a stub
Am 09.08.2013 09:35, schrieb Rusty Russell:
Andreas Färber afaer...@suse.de writes:
[...] If we name it
cpu_get_byteswap() as proposed by you, then its first argument should be
a CPUState *cpu. Its value would be read from the derived type's state,
such as the MSR bit in the code path that
Rusty Russell ru...@rustcorp.com.au writes:
Virtio is currently defined to work as guest endian, but this is a
problem if the guest can change endian. As most targets can't change
endian, we make it a per-target option to avoid pessimising.
This is based on a simpler patch by Anthony
Am 08.08.2013 15:31, schrieb Anthony Liguori:
Rusty Russell ru...@rustcorp.com.au writes:
Virtio is currently defined to work as guest endian, but this is a
problem if the guest can change endian. As most targets can't change
endian, we make it a per-target option to avoid pessimising.
Andreas Färber afaer...@suse.de writes:
Am 08.08.2013 15:31, schrieb Anthony Liguori:
Rusty Russell ru...@rustcorp.com.au writes:
Virtio is currently defined to work as guest endian, but this is a
problem if the guest can change endian. As most targets can't change
endian, we make it a
On Thu, Aug 08, 2013 at 10:40:28AM -0500, Anthony Liguori wrote:
Andreas Färber afaer...@suse.de writes:
We have a mechanism to do weak functions via stubs/. I think it would
be better to do cpu_get_byteswap() as a stub function and then overload
it in the ppc64 code.
If this as your
On 8 August 2013 16:40, Anthony Liguori anth...@codemonkey.ws wrote:
PPC64 is big endian. AFAIK, there is no such thing as a little endian
PPC64 processor.
What's your definition of little endian processor here if
it isn't one which is doing byte swaps of data? I would
describe a PPC64 with
Peter Maydell peter.mayd...@linaro.org writes:
On 8 August 2013 16:40, Anthony Liguori anth...@codemonkey.ws wrote:
PPC64 is big endian. AFAIK, there is no such thing as a little endian
PPC64 processor.
What's your definition of little endian processor here if
it isn't one which is doing
Daniel P. Berrange berra...@redhat.com writes:
On Thu, Aug 08, 2013 at 10:40:28AM -0500, Anthony Liguori wrote:
Andreas Färber afaer...@suse.de writes:
We have a mechanism to do weak functions via stubs/. I think it would
be better to do cpu_get_byteswap() as a stub function and then
On 8 August 2013 17:07, Anthony Liguori anth...@codemonkey.ws wrote:
It's the same processor. It still starts executing big endian
instructions. A magic register value is tweaked and loads/stores are
swapped.
I dunno about PPC, but for ARM generally the boot-up state is
controlled by config
Am 08.08.2013 17:40, schrieb Anthony Liguori:
Andreas Färber afaer...@suse.de writes:
Am 08.08.2013 15:31, schrieb Anthony Liguori:
We have a mechanism to do weak functions via stubs/. I think it would
be better to do cpu_get_byteswap() as a stub function and then overload
it in the ppc64
Peter Maydell peter.mayd...@linaro.org writes:
On 8 August 2013 17:07, Anthony Liguori anth...@codemonkey.ws wrote:
It's the same processor. It still starts executing big endian
instructions. A magic register value is tweaked and loads/stores are
swapped.
I dunno about PPC, but for ARM
On 8 August 2013 17:25, Anthony Liguori anth...@codemonkey.ws wrote:
Peter Maydell peter.mayd...@linaro.org writes:
On 8 August 2013 17:07, Anthony Liguori anth...@codemonkey.ws wrote:
CPU data structures are still read as big endian though.
Do you have an example of what you mean by CPU data
Andreas Färber afaer...@suse.de writes:
Am 08.08.2013 15:31, schrieb Anthony Liguori:
Rusty Russell ru...@rustcorp.com.au writes:
Virtio is currently defined to work as guest endian, but this is a
problem if the guest can change endian. As most targets can't change
endian, we make it a
Anthony Liguori anth...@codemonkey.ws writes:
Daniel P. Berrange berra...@redhat.com writes:
On Thu, Aug 08, 2013 at 10:40:28AM -0500, Anthony Liguori wrote:
Andreas Färber afaer...@suse.de writes:
We have a mechanism to do weak functions via stubs/. I think it would
be better to do
Hi,
The distinction is important in QEMU. ppc64 is still
TARGET_WORDS_BIGENDIAN. We still want most stl_phys to treat
integers as big endian. There's just this extra concept that CPU
loads/stores are sometimes byte swapped. That affects virtio but
not a lot else.
You've
Virtio is currently defined to work as guest endian, but this is a
problem if the guest can change endian. As most targets can't change
endian, we make it a per-target option to avoid pessimising.
This is based on a simpler patch by Anthony Liguouri, which only handled
the vring accesses. We
29 matches
Mail list logo
