On Thu, Jun 27, 2019 at 04:02:24PM +0100, Dave Martin wrote: > Either way, it's entirely reasonable for userspace not to try to support > additional slices for now. We'll have plenty of time to plan away > across that bridge when we spot it on the horizon...
Which makes me inclined to keep the get/put register code the way it is in this patch, at least with regards to the hard coded number of slices and the build-bug. The way it's written (to me) serves to document the state of things, rather than truly implement anything, but also (to me) it's easier to understand that code than would be a couple of paragraphs of actual documentation trying to explain it. > > Within QEMU, it has so far made sense to keep the data in 64-bit hunks in > > host-endian order. That's how the AdvSIMD code was written originally, and > > it > > turned out to be easy enough to continue that for SVE. > > Fair enough. It's entirely up to QEMU to decide -- I just wanted to > check that there was no misunderstanding about this issue in the ABI. We do need to use/swap-to host-endian when we implement the monitor's dump-guest-memory command, at it also creates ELF notes for the general and VFP (and, coming soon, SVE) registers. Implementing those ELF notes for SVE is on my TODO, right after this series. Thanks, drew
