On Tue, May 26, 2026 at 4:08 PM Paulo Fernando Barbosa Duarte <[email protected]> wrote: > To solve this in MI we would need to add support for this type of alignment, > I implemented it on my forks https://github.com/paulofduarte/mig/tree/int128 > and https://github.com/paulofduarte/gnumach/tree/mach-int128 . But we > would also need to use an ABI that has an input using __int128 for it to be > align to that. This means creating a new ABI or changing the existing one. > First option is horrible, as it’ll make porting existing userspace more > complex, > second breaks compatibility with all consumers. So both in my opinion should > not be done.
To clarify what I was saying: because this is a preexisting RPC that is not specific to aarch64_float_state, it makes sense to work around the lack of alignment (with another copy, like your original patch does), rather than try to make MIG 16-align it. > > What I don't remember is how MIG decides whether to pass data in-line > > or out-of-line. Is it dependent on size (i.e. new_state_count)? And if > > the data is transferred out-of-line, does the kernel just get a > > pointer into the user's page? -- possibly unaligned? > > It basically traverse the the message type and calculate the alignment > for every field and compute the overall alignment. If you are interested, > this commit I changed exactly the function that does this calculation on > this commit: But that answers neither of my two questions :) I understand that MIG has some logic to align fields when it does have the right idea about the desired alignment (which is not the case here). But that applies to data passed inline; MIG (and Mach IPC in general) can also pass data out-of-line, which avoids physically copying the data, instead the pages are shared. So I was wondering, how does MIG decide on inline vs out-of-line, and what happens if out-of-line data is misaligned. The former should be easy to answer, just look into the MIG-generated code. Sergey
