On 01/22/2014 12:22 PM, Peter Maydell wrote:
On 22 January 2014 05:39, 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 chat and Christoffer asked me to
On 23 January 2014 18:14, Christoffer Dall wrote:
> On Thu, Jan 23, 2014 at 04:50:18PM -0800, Victor Kamensky wrote:
>> On 23 January 2014 12:45, Christoffer Dall
>> wrote:
>> > On Thu, Jan 23, 2014 at 08:25:35AM -0800, Victor Kamensky wrote:
>> >> On 23 January 2014 07:33, Peter Maydell wrote:
On Thu, Jan 23, 2014 at 04:50:18PM -0800, Victor Kamensky wrote:
> On 23 January 2014 12:45, Christoffer Dall
> wrote:
> > On Thu, Jan 23, 2014 at 08:25:35AM -0800, Victor Kamensky wrote:
> >> On 23 January 2014 07:33, Peter Maydell wrote:
> >> > On 23 January 2014 15:06, Victor Kamensky
> >>
On 23 January 2014 12:45, Christoffer Dall wrote:
> On Thu, Jan 23, 2014 at 08:25:35AM -0800, Victor Kamensky wrote:
>> On 23 January 2014 07:33, Peter Maydell wrote:
>> > On 23 January 2014 15:06, Victor Kamensky
>> > wrote:
>> >> In [1] I wrote
>> >>
>> >> "I don't see why you so attached to
On 23 January 2014 08:25, Victor Kamensky wrote:
> On 23 January 2014 07:33, Peter Maydell wrote:
>> On 23 January 2014 15:06, Victor Kamensky wrote:
>>> In [1] I wrote
>>>
>>> "I don't see why you so attached to desire to describe
>>> data part of memory transaction as just one of int
>>> types
On Thu, Jan 23, 2014 at 08:25:35AM -0800, Victor Kamensky wrote:
> On 23 January 2014 07:33, Peter Maydell wrote:
> > On 23 January 2014 15:06, Victor Kamensky
> > wrote:
> >> In [1] I wrote
> >>
> >> "I don't see why you so attached to desire to describe
> >> data part of memory transaction as
On 23 January 2014 07:33, Peter Maydell wrote:
> On 23 January 2014 15:06, Victor Kamensky wrote:
>> In [1] I 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 i
On 23 January 2014 15:06, Victor Kamensky wrote:
> In [1] I 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
On 23 January 2014 02:23, Peter Maydell wrote:
> On 23 January 2014 00:22, Victor Kamensky wrote:
>> Peter, could I please ask you a favor. Could you please
>> stop deleting pieces of your and my previous responses
>> when you reply.
>
> No, sorry. It produces excessively long and totally unreada
On 23 January 2014 00:22, Victor Kamensky wrote:
> Peter, could I please ask you a favor. Could you please
> stop deleting pieces of your and my previous responses
> when you reply.
No, sorry. It produces excessively long and totally unreadable
emails for everybody else if people don't trim for c
Peter, could I please ask you a favor. Could you please
stop deleting pieces of your and my previous responses
when you reply.
Please just reply inline. Sometimes I would like to
reference my or your previous statement, but I could not
find it in your response email. It is very bizzar. Sorry,
it wi
On 22 January 2014 22:47, Victor Kamensky wrote:
> You deleted my example, but I need it again:
> Consider the following ARM code snippets:
>
> setend le
> mov r1, #0x04030201
> str r1, [r0]
>
> and
>
> setend be
> mov r1, #0x01020304
> str r1, [r0]
>
> Just for LE host case basically you are sayi
On 22 January 2014 12:02, Peter Maydell wrote:
> On 22 January 2014 19:29, Victor Kamensky wrote:
>> On 22 January 2014 09:29, Peter Maydell wrote:
>>> This just isn't how real buses work. There is no
>>> "address + 1, address + 2". There is a single address
>>> for the memory transaction and a
On 22 January 2014 19:29, Victor Kamensky wrote:
> On 22 January 2014 09:29, Peter Maydell wrote:
>> This just isn't how real buses work. There is no
>> "address + 1, address + 2". There is a single address
>> for the memory transaction and a set of data on
>> data lines and some separate size in
On 22 January 2014 09:29, Peter Maydell wrote:
> On 22 January 2014 17:19, Victor Kamensky wrote:
>> On 22 January 2014 02:22, Peter Maydell wrote:
>>> but the major issue here is that the data being
>>> transferred is not just a bag of bytes. The data[]
>>> array plus the size field are being (
On 22 January 2014 17:19, Victor Kamensky wrote:
> On 22 January 2014 02:22, Peter Maydell wrote:
>> but the major issue here is that the data being
>> transferred is not just a bag of bytes. The data[]
>> array plus the size field are being (mis)used to indicate
>> that the memory transaction is
Hi Peter,
On 22 January 2014 02:22, Peter Maydell wrote:
> On 22 January 2014 05:39, 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 cha
On 22 January 2014 05:39, 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 chat and Christoffer asked me to follow
> up on this thread.
> Here it
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 chat and Christoffer asked me to follow
up on this thread.
Here it goes. Sorry, it is very long email.
I don't believe we can assi
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 chat and Christoffer asked me to follow
> up on this thread.
>
On Mon, Jan 20, 2014 at 03:22:11PM +0100, Alexander Graf wrote:
>
> On 17.01.2014, at 19:52, Peter Maydell wrote:
>
> > On 17 January 2014 17:53, Peter Maydell wrote:
> >> Specifically, the KVM API says "here's a uint8_t[] byte
> >> array and a length", and the current QEMU code treats that
> >
On 17.01.2014, at 19:52, Peter Maydell wrote:
> On 17 January 2014 17:53, Peter Maydell wrote:
>> Specifically, the KVM API says "here's a uint8_t[] byte
>> array and a length", and the current QEMU code treats that
>> as "this is a byte array written as if the guest CPU
>> (a) were in TARGET_W
On 18.01.2014, at 11:15, Peter Maydell wrote:
> On 18 January 2014 07:32, Alexander Graf wrote:
>>> Am 18.01.2014 um 05:24 schrieb Christoffer Dall
>>> :
On Fri, Jan 17, 2014 at 06:52:57PM +, Peter Maydell wrote:
Having thought a little more about this, my opinion is:
On 20 January 2014 14:20, Alexander Graf wrote:
> I think I see the problem now. You're thinking about LE hosts, not LE guests.
>
> I think the only really sensible options would be to
>
> a) Always use a statically define target endianness (big for ppc)
> b) Always use host endianness
> Curr
On 18 January 2014 07:32, Alexander Graf wrote:
>> Am 18.01.2014 um 05:24 schrieb Christoffer Dall
>> :
>>> On Fri, Jan 17, 2014 at 06:52:57PM +, Peter Maydell wrote:
>>> Having thought a little more about this, my opinion is:
>>>
>>> * we should specify that the byte order of the mmio.data
>
> Am 18.01.2014 um 05:24 schrieb Christoffer Dall :
>
>> On Fri, Jan 17, 2014 at 06:52:57PM +, Peter Maydell wrote:
>>> On 17 January 2014 17:53, Peter Maydell wrote:
>>> Specifically, the KVM API says "here's a uint8_t[] byte
>>> array and a length", and the current QEMU code treats that
>
On Fri, Jan 17, 2014 at 06:52:57PM +, Peter Maydell wrote:
> On 17 January 2014 17:53, Peter Maydell wrote:
> > Specifically, the KVM API says "here's a uint8_t[] byte
> > array and a length", and the current QEMU code treats that
> > as "this is a byte array written as if the guest CPU
> > (a
On 17 January 2014 17:53, Peter Maydell wrote:
> Specifically, the KVM API says "here's a uint8_t[] byte
> array and a length", and the current QEMU code treats that
> as "this is a byte array written as if the guest CPU
> (a) were in TARGET_WORDS_BIGENDIAN order and (b) wrote its
> I/O access to
[This seemed like a good jumping off point for this question.]
On 16 January 2014 17:51, Alexander Graf wrote:
> Am 16.01.2014 um 18:41 schrieb Peter Maydell :
>> Also see my remarks on the previous patch series suggesting
>> that we should look at this in a more holistic way than
>> just randoml
29 matches
Mail list logo
