On Tue, Oct 11, 2016 at 09:55:54AM +0100, Peter Maydell wrote:
> On 11 October 2016 at 02:24, David Gibson wrote:
> > On Mon, Oct 10, 2016 at 03:10:33PM +0100, Peter Maydell wrote:
> >> On 10 October 2016 at 14:39, David Gibson
> >> wrote:
> >> > In the overwhelming majority of cases the endiann
On 11 October 2016 at 02:24, David Gibson wrote:
> On Mon, Oct 10, 2016 at 03:10:33PM +0100, Peter Maydell wrote:
>> On 10 October 2016 at 14:39, David Gibson
>> wrote:
>> > In the overwhelming majority of cases the endianness of the device is
>> > known independent of the guest CPU and board.
>
On Tue, Oct 11, 2016 at 12:24:29PM +1100, David Gibson wrote:
> On Mon, Oct 10, 2016 at 03:10:33PM +0100, Peter Maydell wrote:
> > On 10 October 2016 at 14:39, David Gibson
> > wrote:
> > > In the overwhelming majority of cases the endianness of the device is
> > > known independent of the guest
On Mon, Oct 10, 2016 at 03:10:33PM +0100, Peter Maydell wrote:
> On 10 October 2016 at 14:39, David Gibson wrote:
> > In the overwhelming majority of cases the endianness of the device is
> > known independent of the guest CPU and board.
>
> We don't seem to model things that way:
>
> $ git grep
On 10 October 2016 at 14:39, David Gibson wrote:
> In the overwhelming majority of cases the endianness of the device is
> known independent of the guest CPU and board.
We don't seem to model things that way:
$ git grep '.endianness = DEVICE_NATIVE' |wc -l
341
$ git grep '.endianness = DEVICE_BI
On Mon, Oct 10, 2016 at 10:18:40AM +0100, Peter Maydell wrote:
> On 10 October 2016 at 05:55, David Gibson wrote:
> > However right now - until we get fixed-endianness qtest accessors of
> > some sort - this test is more or less necessary to make most tests
> > cross platform correct (except PCI,
On 10 October 2016 at 05:55, David Gibson wrote:
> However right now - until we get fixed-endianness qtest accessors of
> some sort - this test is more or less necessary to make most tests
> cross platform correct (except PCI, see below). That's because the
> testcase will generally know the endi
On Fri, Oct 07, 2016 at 12:48:49PM +0200, Greg Kurz wrote:
> On Fri, 7 Oct 2016 12:14:27 +0200
> Laurent Vivier wrote:
>
> > The target endianness is not deduced anymore from
> > the architecture name but asked directly to the guest,
> > using a new qtest command: "endianness". As it can't
> > c
On Fri, Oct 07, 2016 at 12:14:27PM +0200, Laurent Vivier wrote:
> The target endianness is not deduced anymore from
> the architecture name but asked directly to the guest,
> using a new qtest command: "endianness". As it can't
> change (this is the value of TARGET_WORDS_BIGENDIAN),
> we store it t
On Fri, 7 Oct 2016 14:56:26 +0200
Laurent Vivier wrote:
> On 07/10/2016 14:52, Peter Maydell wrote:
> > On 7 October 2016 at 13:45, Greg Kurz wrote:
> >> On Fri, 7 Oct 2016 13:31:10 +0100
> >> Peter Maydell wrote:
> >>
> >>> On 7 October 2016 at 13:27, Greg Kurz wrote:
> Indeed but
On 07/10/2016 14:52, Peter Maydell wrote:
> On 7 October 2016 at 13:45, Greg Kurz wrote:
>> On Fri, 7 Oct 2016 13:31:10 +0100
>> Peter Maydell wrote:
>>
>>> On 7 October 2016 at 13:27, Greg Kurz wrote:
Indeed but my suggestion is to open code this in qvirtio_is_big_endian(),
and even
On 7 October 2016 at 13:45, Greg Kurz wrote:
> On Fri, 7 Oct 2016 13:31:10 +0100
> Peter Maydell wrote:
>
>> On 7 October 2016 at 13:27, Greg Kurz wrote:
>> > Indeed but my suggestion is to open code this in qvirtio_is_big_endian(),
>> > and even rename QTestState::big_endian to virtio_big_endia
On Fri, 7 Oct 2016 13:31:10 +0100
Peter Maydell wrote:
> On 7 October 2016 at 13:27, Greg Kurz wrote:
> > Indeed but my suggestion is to open code this in qvirtio_is_big_endian(),
> > and even rename QTestState::big_endian to virtio_big_endian to make it
> > really obvious it should not be used
On 7 October 2016 at 13:27, Greg Kurz wrote:
> Indeed but my suggestion is to open code this in qvirtio_is_big_endian(),
> and even rename QTestState::big_endian to virtio_big_endian to make it
> really obvious it should not be used elsewhere.
>
> I now remember this is what I was resolutely sugge
On Fri, 7 Oct 2016 12:57:41 +0200
Laurent Vivier wrote:
> On 07/10/2016 12:48, Greg Kurz wrote:
> > On Fri, 7 Oct 2016 12:14:27 +0200
> > Laurent Vivier wrote:
> >
> >> The target endianness is not deduced anymore from
> >> the architecture name but asked directly to the guest,
> >> using a
On 07/10/2016 12:48, Greg Kurz wrote:
> On Fri, 7 Oct 2016 12:14:27 +0200
> Laurent Vivier wrote:
>
>> The target endianness is not deduced anymore from
>> the architecture name but asked directly to the guest,
>> using a new qtest command: "endianness". As it can't
>> change (this is the valu
On Fri, 7 Oct 2016 12:14:27 +0200
Laurent Vivier wrote:
> The target endianness is not deduced anymore from
> the architecture name but asked directly to the guest,
> using a new qtest command: "endianness". As it can't
> change (this is the value of TARGET_WORDS_BIGENDIAN),
> we store it to not
The target endianness is not deduced anymore from
the architecture name but asked directly to the guest,
using a new qtest command: "endianness". As it can't
change (this is the value of TARGET_WORDS_BIGENDIAN),
we store it to not have to ask every time we want to
know if we have to byte-swap a val
18 matches
Mail list logo
