Just drop the __packed annotations then, they just confuse the compilerin this case. In particular, when the compiler thinks that a structure ismisaligned, it tries to avoid using load/store instructions on it that areinefficient or trap with misaligned code, so having default alignmentproduces better object code.

> > Also, in order to write portable code, it would be helpful to mark> > all the fields as explicitly little-endian, and use __le32_to_cpu()> > etc for accessing them.>> There's an opening comment in this file stating that all data> structures shared between Hyper-V and a guest VM are little> endian. Is there some other marking to consider using?

> We have definitely not allowed for the case of Hyper-V running on> a big endian architecture. There are a *lot* of messages and data> structures passed between the guest and Hyper-V, and coding> to handle either endianness is a big project. I'm doubtful> of the value until and unless we actually have a need for it.

In general, the use of big-endian software on Linux is declining, however

- arm64 as an architecture is meant to support both endian types, and we still try to ensure it works either way as long as there are users that depend on it.

- The remaining users of big-endian software are probably more likely to run on virtual machines than on real hardware

- Any device driver should generally be written against portable interfaces, even if you think you know how it will be used. As driver writers tend to look at existing code for new drivers, it's better to have them all be portable. (This is a similar argument to the irqchip interface).

Even if you don't convert any of the existing architecture independentcode to run both ways, I see no reason to not do it for new drivers.