On Mon, May 30, 2016 at 12:16 PM, Peter Xu <pet...@redhat.com> wrote:
> On Mon, May 30, 2016 at 11:54:52AM +0300, David Kiarie wrote:
>> On Mon, May 30, 2016 at 11:14 AM, Peter Xu <pet...@redhat.com> wrote:
>> > On Mon, May 30, 2016 at 07:56:16AM +0200, Jan Kiszka wrote:
>> >> On 2016-05-30 07:45, Peter Xu wrote:
> [...]
>> >> >
>> >> > I assume you mean when host cpu is big endian. x86 was little endian,
>> >> > and I was testing on x86.
>> >> >
>> >> > I think you are right. I should do conditional byte swap for all
>> >> > uint{16/32/64} cases within the fields. For example, index_l field in
>> >> > above VTD_IR_MSIAddress. And there are several other cases that need
>> >> > special treatment in the patchset. Will go over and fix corresponding
>> >> > issues in next version.
>> >>
>> >> You actually need bit-swap with bit fields, see e.g. hw/net/vmxnet3.h.
>> >
>> > Not noticed about bit-field ordering before... So maybe I need both?
>>
>> Yes, I think we will need both though, I think, byte swapping the
>> whole struct will break the code but swapping individual fields is
>> what we need.
>>
>> Myself, I'm defining bitfields as below:
>>
>>   struct CMDCompletionWait {
>>
>> #ifdef __BIG_ENDIAN_BITFIELD
>>     uint32_t type:4;               /* command type           */
>>     uint32_t reserved:8;
>>     uint64_t store_addr:49;        /* addr to write          */
>>     uint32_t completion_flush:1;   /* allow more executions  */
>>     uint32_t completion_int:1;     /* set MMIOWAITINT        */
>>     uint32_t completion_store:1;   /* write data to address  */
>
> I guess what we need might be this one:
>
>       uint64_t type:4;               /* command type           */
>       uint64_t reserved:8;
>       uint64_t store_addr:49;        /* addr to write          */
>       uint64_t completion_flush:1;   /* allow more executions  */
>       uint64_t completion_int:1;     /* set MMIOWAITINT        */
>       uint64_t completion_store:1;   /* write data to address  */
>
> IIUC, if we define type:4 as uint32_t rather than uint64_t, it should
> be bits [29:32] of the struct on big endian machines, not bits
> [61:64].

Yes, you're right.

>
> Thanks,
>
> -- peterx

Reply via email to