On 7 October 2016 at 00:31, David Gibson wrote:
> Honestly I think TAGET_WORDS_BIGENDIAN is just a hangover from when
> nearly all CPUs worked exclusively in one endianness. It's never
> terribly well defined.
Feel free to try to get rid of it, but it's baked into the
KVM ABI as a concept and al
On 07/10/2016 01:34, David Gibson wrote:
>> On 06/10/2016 17:41, Peter Maydell wrote:
>>> Speaking of the right place to do things, perhaps we should
>>> reimplement qtest_big_endian() in libqtest.c to send a query
>>> to the QEMU-under-test to ask it what TARGET_BIG_ENDIAN says,
>>> rather than
On Thu, Oct 06, 2016 at 12:03:34PM +0100, Peter Maydell wrote:
> On 6 October 2016 at 04:38, David Gibson wrote:
> > On Wed, Oct 05, 2016 at 05:31:07AM -0700, Peter Maydell wrote:
> >> On 4 October 2016 at 16:43, David Gibson
> >> wrote:
> >> > On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter May
On Thu, Oct 06, 2016 at 05:59:00PM +0200, Laurent Vivier wrote:
>
>
> On 06/10/2016 17:41, Peter Maydell wrote:
> > On 6 October 2016 at 16:36, Paolo Bonzini wrote:
> >>
> >>
> >> On 06/10/2016 16:11, Greg Kurz wrote:
> >>> FWIW, Cedric had another proposal which apparently went unnoticed:
> >>>
On Thu, Oct 06, 2016 at 05:36:32PM +0200, Paolo Bonzini wrote:
>
>
> On 06/10/2016 16:11, Greg Kurz wrote:
> > FWIW, Cedric had another proposal which apparently went unnoticed:
> >
> >
> >
> > The idea is to add an optional endianness argument to the read*/write*
> > commands in the qtest pro
On Thu, Oct 06, 2016 at 04:11:42PM +0200, Greg Kurz wrote:
> On Thu, 6 Oct 2016 12:03:34 +0100
> Peter Maydell wrote:
>
> > On 6 October 2016 at 04:38, David Gibson
> > wrote:
> > > On Wed, Oct 05, 2016 at 05:31:07AM -0700, Peter Maydell wrote:
> > >> On 4 October 2016 at 16:43, David Gibson
On Thu, Oct 06, 2016 at 11:47:36AM +0100, Peter Maydell wrote:
> On 6 October 2016 at 04:45, David Gibson wrote:
> > On Wed, Oct 05, 2016 at 07:20:52AM -0700, Peter Maydell wrote:
> >> On 5 October 2016 at 07:00, Cédric Le Goater wrote:
> >> > On 10/05/2016 03:53 PM, Peter Maydell wrote:
> >> >>
On 06/10/2016 17:41, Peter Maydell wrote:
> On 6 October 2016 at 16:36, Paolo Bonzini wrote:
>>
>>
>> On 06/10/2016 16:11, Greg Kurz wrote:
>>> FWIW, Cedric had another proposal which apparently went unnoticed:
>>>
>>>
>>>
>>> The idea is to add an optional endianness argument to the read*/writ
On 10/06/2016 05:36 PM, Paolo Bonzini wrote:
>
>
> On 06/10/2016 16:11, Greg Kurz wrote:
>> FWIW, Cedric had another proposal which apparently went unnoticed:
>>
>>
>>
>> The idea is to add an optional endianness argument to the read*/write*
>> commands in the qtest protocol:
>> - libqtest then
On 06/10/2016 17:44, Cédric Le Goater wrote:
> On 10/06/2016 05:36 PM, Paolo Bonzini wrote:
>>
>>
>> On 06/10/2016 16:11, Greg Kurz wrote:
>>> FWIW, Cedric had another proposal which apparently went unnoticed:
>>>
>>>
>>>
>>> The idea is to add an optional endianness argument to the read*/write*
On 6 October 2016 at 16:36, Paolo Bonzini wrote:
>
>
> On 06/10/2016 16:11, Greg Kurz wrote:
>> FWIW, Cedric had another proposal which apparently went unnoticed:
>>
>>
>>
>> The idea is to add an optional endianness argument to the read*/write*
>> commands in the qtest protocol:
>> - libqtest th
On 06/10/2016 16:11, Greg Kurz wrote:
> FWIW, Cedric had another proposal which apparently went unnoticed:
>
>
>
> The idea is to add an optional endianness argument to the read*/write*
> commands in the qtest protocol:
> - libqtest then provides explicit _le and _be APIs
> - no extra byteswap
On Thu, 6 Oct 2016 12:03:34 +0100
Peter Maydell wrote:
> On 6 October 2016 at 04:38, David Gibson wrote:
> > On Wed, Oct 05, 2016 at 05:31:07AM -0700, Peter Maydell wrote:
> >> On 4 October 2016 at 16:43, David Gibson
> >> wrote:
> >> > On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter Mayde
On 6 October 2016 at 04:38, David Gibson wrote:
> On Wed, Oct 05, 2016 at 05:31:07AM -0700, Peter Maydell wrote:
>> On 4 October 2016 at 16:43, David Gibson wrote:
>> > On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter Maydell wrote:
>> >> The difficulty with this patch is that it's hard to tell wh
On 6 October 2016 at 04:45, David Gibson wrote:
> On Wed, Oct 05, 2016 at 07:20:52AM -0700, Peter Maydell wrote:
>> On 5 October 2016 at 07:00, Cédric Le Goater wrote:
>> > On 10/05/2016 03:53 PM, Peter Maydell wrote:
>> >> Which tswap? Last time I worked through the stack of
>> >> what happens I
On 10/06/2016 11:40 AM, Paolo Bonzini wrote:
>
>
> On 06/10/2016 10:37, David Gibson wrote:
>> On Thu, Oct 06, 2016 at 09:23:11AM +0200, Paolo Bonzini wrote:
>>>
>>>
>>> On 06/10/2016 05:45, David Gibson wrote:
qtest is about testing hardware, not the guest cpu, and whether you're
acces
On 06/10/2016 10:37, David Gibson wrote:
> On Thu, Oct 06, 2016 at 09:23:11AM +0200, Paolo Bonzini wrote:
>>
>>
>> On 06/10/2016 05:45, David Gibson wrote:
>>> qtest is about testing hardware, not the guest cpu, and whether you're
>>> accessing MMIO space or buffers the hardware will read via DMA
On Thu, Oct 06, 2016 at 09:23:11AM +0200, Paolo Bonzini wrote:
>
>
> On 06/10/2016 05:45, David Gibson wrote:
> > qtest is about testing hardware, not the guest cpu, and whether you're
> > accessing MMIO space or buffers the hardware will read via DMA, it's
> > the hardware which determines the c
On 06/10/2016 05:45, David Gibson wrote:
> qtest is about testing hardware, not the guest cpu, and whether you're
> accessing MMIO space or buffers the hardware will read via DMA, it's
> the hardware which determines the correct endianness, not the guest
> cpu.
Well, sort of... qtest writes are
On Thu, Oct 06, 2016 at 02:38:36PM +1100, David Gibson wrote:
> On Wed, Oct 05, 2016 at 05:31:07AM -0700, Peter Maydell wrote:
> > On 4 October 2016 at 16:43, David Gibson
> > wrote:
> > > On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter Maydell wrote:
> > >> The difficulty with this patch is that
On Wed, Oct 05, 2016 at 05:31:07AM -0700, Peter Maydell wrote:
> On 4 October 2016 at 16:43, David Gibson wrote:
> > On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter Maydell wrote:
> >> The difficulty with this patch is that it's hard to tell whether
> >> it's really required, or if this is just ad
On Wed, Oct 05, 2016 at 03:49:18PM +0200, Cédric Le Goater wrote:
> On 10/05/2016 02:31 PM, Peter Maydell wrote:
> > On 4 October 2016 at 16:43, David Gibson
> > wrote:
> >> On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter Maydell wrote:
> >>> The difficulty with this patch is that it's hard to te
On Wed, Oct 05, 2016 at 07:20:52AM -0700, Peter Maydell wrote:
> On 5 October 2016 at 07:00, Cédric Le Goater wrote:
> > On 10/05/2016 03:53 PM, Peter Maydell wrote:
> >> Which tswap? Last time I worked through the stack of
> >> what happens I thought that we had the right set of
> >> swaps in the
On 5 October 2016 at 10:17, Cédric Le Goater wrote:
> OK. I think my brain is starting to see things from the right
> angle.
>
> Let's try that : my test is simulating a Little Endian CPU which
> is writing a Big Endian value, so it *always* needs to bswap()
> that value.
Yes. If your code on the
On 10/05/2016 04:20 PM, Peter Maydell wrote:
> On 5 October 2016 at 07:00, Cédric Le Goater wrote:
>> On 10/05/2016 03:53 PM, Peter Maydell wrote:
>>> Which tswap? Last time I worked through the stack of
>>> what happens I thought that we had the right set of
>>> swaps in the right places.
>>
>> T
On 5 October 2016 at 07:00, Cédric Le Goater wrote:
> On 10/05/2016 03:53 PM, Peter Maydell wrote:
>> Which tswap? Last time I worked through the stack of
>> what happens I thought that we had the right set of
>> swaps in the right places.
>
> The one I am talking about are under qtest_process_com
On 10/05/2016 03:53 PM, Peter Maydell wrote:
> On 5 October 2016 at 06:49, Cédric Le Goater wrote:
>> On 10/05/2016 02:31 PM, Peter Maydell wrote:
>>> Here I definitely disagree. I think it makes much more sense
>>> for writes to be "what the guest CPU would write", because that's
>>> where we're
On 5 October 2016 at 06:49, Cédric Le Goater wrote:
> On 10/05/2016 02:31 PM, Peter Maydell wrote:
>> Here I definitely disagree. I think it makes much more sense
>> for writes to be "what the guest CPU would write", because that's
>> where we're injecting them. If we had a test framework where th
On 10/05/2016 02:31 PM, Peter Maydell wrote:
> On 4 October 2016 at 16:43, David Gibson wrote:
>> On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter Maydell wrote:
>>> The difficulty with this patch is that it's hard to tell whether
>>> it's really required, or if this is just adding an extra layer
>
On 4 October 2016 at 16:43, David Gibson wrote:
> On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter Maydell wrote:
>> The difficulty with this patch is that it's hard to tell whether
>> it's really required, or if this is just adding an extra layer
>> of byteswapping that should really be done in so
On 10/05/2016 01:43 AM, David Gibson wrote:
> On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter Maydell wrote:
>> On 4 October 2016 at 13:17, Cédric Le Goater wrote:
>>> Some test scenarios require to access memory regions using a specific
>>> endianness, such as a device region, but the current qte
On 10/05/2016 01:26 AM, David Gibson wrote:
> On Tue, Oct 04, 2016 at 02:17:28PM +0200, Cédric Le Goater wrote:
>> Some test scenarios require to access memory regions using a specific
>> endianness, such as a device region, but the current qtest memory
>> accessors are done in native endian, which
On Tue, Oct 04, 2016 at 02:17:28PM +0200, Cédric Le Goater wrote:
> Some test scenarios require to access memory regions using a specific
> endianness, such as a device region, but the current qtest memory
> accessors are done in native endian, which means that the values are
> byteswapped in qtest
On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter Maydell wrote:
> On 4 October 2016 at 13:17, Cédric Le Goater wrote:
> > Some test scenarios require to access memory regions using a specific
> > endianness, such as a device region, but the current qtest memory
> > accessors are done in native endi
On 04/10/2016 14:36, Peter Maydell wrote:
> > - first, convert the value to the required endianness in libqtest and
> > then use the memread/write routines so that qtest accesses the guest
> > memory without doing any supplementary byteswapping
> >
> > - an alternative method would be to hand
On 04/10/2016 14:36, Peter Maydell wrote:
> On 4 October 2016 at 13:17, Cédric Le Goater wrote:
>> Some test scenarios require to access memory regions using a specific
>> endianness, such as a device region, but the current qtest memory
>> accessors are done in native endian, which means that t
On 10/04/2016 02:36 PM, Peter Maydell wrote:
> On 4 October 2016 at 13:17, Cédric Le Goater wrote:
>> Some test scenarios require to access memory regions using a specific
>> endianness, such as a device region, but the current qtest memory
>> accessors are done in native endian, which means that
On 4 October 2016 at 13:17, Cédric Le Goater wrote:
> Some test scenarios require to access memory regions using a specific
> endianness, such as a device region, but the current qtest memory
> accessors are done in native endian, which means that the values are
> byteswapped in qtest if the endia
Some test scenarios require to access memory regions using a specific
endianness, such as a device region, but the current qtest memory
accessors are done in native endian, which means that the values are
byteswapped in qtest if the endianness of the guest and the host are
different.
To maintain t
39 matches
Mail list logo
