On Tue, Jan 28, 2014 at 03:47:32PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-01-27 at 16:44 -0800, Christoffer Dall wrote:
>
> > I'm loosing track of this discussion, Ben, can you explain a bit? You
> > wrote:
> >
> > Having a byte array coming in that represents what the CPU does in
On 01/28/2014 01:27 AM, Benjamin Herrenschmidt wrote:
On Wed, 2014-01-22 at 17:29 +, Peter Maydell wrote:
Basically if it would be on real bus, get byte value
that corresponds to phys_addr + 0 address place
it into data[0], get byte value that corresponds to
phys_addr + 1 address place it in
On Mon, 2014-01-27 at 16:44 -0800, Christoffer Dall wrote:
> I'm loosing track of this discussion, Ben, can you explain a bit? You
> wrote:
>
> Having a byte array coming in that represents what the CPU does in its
> current byte order means you do *NOT* need to query the endianness of
> t
On Tue, Jan 28, 2014 at 11:36:13AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-01-27 at 23:49 +, Peter Maydell wrote:
> >
> > Er, what? If we make the array be guest's current order
> > then by definition userspace has to look at the guest's
> > current endianness. I agree that would b
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 abo
On Mon, 2014-01-27 at 23:49 +, Peter Maydell wrote:
>
> Er, what? If we make the array be guest's current order
> then by definition userspace has to look at the guest's
> current endianness. I agree that would be bad. Either
> of the two current proposals (host kernel order; guest
> CPU's nat
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 integ
> The point is simple, and Peter has made it over and over:
> Any consumer of a memory operation sees "value, len, address".
>
> This is what KVM_EXIT_MMIO emulates. So just by knowing the ABI
> definition and having a pointer to the structure you need to be able to
> tell me "value, len, addres
On Tue, 2014-01-28 at 11:07 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2014-01-23 at 15:33 +, Peter Maydell wrote:
> > (4) PPC CPUs in BE mode and ARM CPUs in BE mode are not
> > the same, because in the ARM case it is doing an
> > internal-to-CPU byteswap, and in the PPC case it
On Thu, 2014-01-23 at 15:33 +, Peter Maydell wrote:
> (4) PPC CPUs in BE mode and ARM CPUs in BE mode are not
> the same, because in the ARM case it is doing an
> internal-to-CPU byteswap, and in the PPC case it is not
Aren't they both byte-order invariant ?
In that case they are t
On 27 January 2014 23:34, Benjamin Herrenschmidt
wrote:
> On Wed, 2014-01-22 at 20:02 +, Peter Maydell wrote:
>>
>> Defining it as being always guest-order would mean that
>> userspace had to continually look at the guest CPU
>> endianness bit, which is annoying and awkward.
>>
>> Defining it
On Wed, 2014-01-22 at 20:02 +, Peter Maydell wrote:
>
> Defining it as being always guest-order would mean that
> userspace had to continually look at the guest CPU
> endianness bit, which is annoying and awkward.
>
> Defining it as always host-endian order is the most
> reasonable option ava
On Wed, 2014-01-22 at 11:29 -0800, Victor Kamensky wrote:
> I don't see why you so attached to desire to describe
> data part of memory transaction as just one of int
> types. If we are talking about bunch of hypothetical
> cases imagine such bus that allow transaction with
> size of 6 bytes. How d
On Wed, 2014-01-22 at 17:29 +, Peter Maydell wrote:
>
> > Basically if it would be on real bus, get byte value
> > that corresponds to phys_addr + 0 address place
> > it into data[0], get byte value that corresponds to
> > phys_addr + 1 address place it into data[1], etc.
>
> This just isn't
On Wed, Jan 22, 2014 at 02:27:29PM +0530, Anup Patel wrote:
[...]
>
> Thanks for the info on QEMU side handling of MMIO data.
>
> I was not aware that we would be only have "target endian = LE"
> for ARM/ARM64 in QEMU. I think Marc Z had mentioned similar
> thing about MMIO this in our previous
On Wed, 22 Jan 2014 20:25:05 -0800
Victor Kamensky wrote:
> Hi Alex,
>
> Sorry, for delayed reply, I was focusing on discussion
> with Peter. Hope you and other folks may get something
> out of it :).
>
> Please see responses inline
>
> On 22 January 2014 02:52, Alexander Graf wrote:
> >
> >
On 23.01.2014, at 05:25, Victor Kamensky wrote:
> Hi Alex,
>
> Sorry, for delayed reply, I was focusing on discussion
> with Peter. Hope you and other folks may get something
> out of it :).
>
> Please see responses inline
>
> On 22 January 2014 02:52, Alexander Graf wrote:
>>
>> On 22.01.2
Hi Alex,
Sorry, for delayed reply, I was focusing on discussion
with Peter. Hope you and other folks may get something
out of it :).
Please see responses inline
On 22 January 2014 02:52, Alexander Graf wrote:
>
> On 22.01.2014, at 08:26, Victor Kamensky wrote:
>
>> On 21 January 2014 22:41, Al
On 22.01.2014, at 08:26, Victor Kamensky wrote:
> On 21 January 2014 22:41, Alexander Graf wrote:
>>
>>
>> "Native endian" really is just a shortcut for "target endian"
>> which is LE for ARM and BE for PPC. There shouldn't be
>> a qemu-system-armeb or qemu-system-ppc64le.
>
> I disagree. Fu
Hi Alex,
On Wed, Jan 22, 2014 at 12:11 PM, Alexander Graf wrote:
>
>
>> Am 22.01.2014 um 07:31 schrieb Anup Patel :
>>
>> On Wed, Jan 22, 2014 at 11:09 AM, Victor Kamensky
>> wrote:
>>> Hi Guys,
>>>
>>> Christoffer and I had a bit heated chat :) on this
>>> subject last night. Christoffer, reall
On 21 January 2014 22:41, Alexander Graf wrote:
>
>
>> Am 22.01.2014 um 07:31 schrieb Anup Patel :
>>
>> On Wed, Jan 22, 2014 at 11:09 AM, Victor Kamensky
>> wrote:
>>> Hi Guys,
>>>
>>> Christoffer and I had a bit heated chat :) on this
>>> subject last night. Christoffer, really appreciate
>>> y
> Am 22.01.2014 um 07:31 schrieb Anup Patel :
>
> On Wed, Jan 22, 2014 at 11:09 AM, Victor Kamensky
> wrote:
>> Hi Guys,
>>
>> Christoffer and I had a bit heated chat :) on this
>> subject last night. Christoffer, really appreciate
>> your time! We did not really reach agreement
>> during the
22 matches
Mail list logo
