Peter Maydell writes:
> On 9 August 2013 08:35, Rusty Russell 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 d
On Mon, 2013-08-12 at 09:58 +0930, Rusty Russell wrote:
> Benjamin Herrenschmidt 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
Benjamin Herrenschmidt 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 virtio to suddenly chan
Anthony Liguori writes:
> Rusty Russell 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: 496
> MAX: 1055
> A
Am 09.08.2013 09:35, schrieb Rusty Russell:
> Andreas Färber 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 you wanted
Am 09.08.2013 09:00, schrieb Rusty Russell:
> Andreas Färber writes:
>> Am 08.08.2013 15:31, schrieb Anthony Liguori:
>>> Rusty Russell 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
>>
Rusty Russell writes:
> Anthony Liguori writes:
>> "Daniel P. Berrange" 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 loads/stores
>> are s
Rusty Russell writes:
> Anthony Liguori 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 shou
On 9 August 2013 03:58, Rusty Russell wrote:
> Anthony Liguori 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 loads/stores
>> are sometimes byte
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 no
On 9 August 2013 08:35, Rusty Russell 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 be in the
global var
Andreas Färber writes:
> Am 08.08.2013 17:40, schrieb Anthony Liguori:
>> Andreas Färber 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 overlo
Andreas Färber writes:
> Am 08.08.2013 15:31, schrieb Anthony Liguori:
>> Rusty Russell 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 name in
Anthony Liguori 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 job optimizing
>
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'
Anthony Liguori writes:
> "Daniel P. Berrange" writes:
>
>> On Thu, Aug 08, 2013 at 10:40:28AM -0500, Anthony Liguori wrote:
>>> Andreas Färber 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 t
Andreas Färber writes:
> Am 08.08.2013 15:31, schrieb Anthony Liguori:
>> Rusty Russell 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 avoi
On 8 August 2013 17:25, Anthony Liguori wrote:
> Peter Maydell writes:
>> On 8 August 2013 17:07, Anthony Liguori wrote:
>>> CPU data structures are still read as big endian though.
>>
>> Do you have an example of what you mean by "CPU data structure"?
>
> MMU tlb hash table. If you grep ldl ta
Peter Maydell writes:
> On 8 August 2013 17:07, Anthony Liguori 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
> contro
Am 08.08.2013 17:40, schrieb Anthony Liguori:
> Andreas Färber 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 code.
>
On 8 August 2013 17:07, Anthony Liguori 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 signals which a SoC
"Daniel P. Berrange" writes:
> On Thu, Aug 08, 2013 at 10:40:28AM -0500, Anthony Liguori wrote:
>> Andreas Färber 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 ppc
Peter Maydell writes:
> On 8 August 2013 16:40, Anthony Liguori 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
> descr
On 8 August 2013 16:40, Anthony Liguori 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 the relevant mode
On Thu, Aug 08, 2013 at 10:40:28AM -0500, Anthony Liguori wrote:
> Andreas Färber 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 name
Andreas Färber writes:
> Am 08.08.2013 15:31, schrieb Anthony Liguori:
>> Rusty Russell 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 avo
Am 08.08.2013 15:31, schrieb Anthony Liguori:
> Rusty Russell 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 ba
Rusty Russell 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 Liguouri, which only
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 a
29 matches
Mail list logo
