Re: [Qemu-devel] [PATCH v7 07/25] intel_iommu: define several structs for IOMMU IR

[Peter Xu]

On Mon, May 30, 2016 at 11:54:52AM +0300, David Kiarie wrote:
> On Mon, May 30, 2016 at 11:14 AM, Peter Xu <address@hidden> 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].

Thanks,

-- peterx