[londons_explore]

> The ARM servers we were working on, however, ignored a higher different number of LSBs. Therefore, when dc zva was called inside bzero, more bytes than expected were set to 0

Let that sink in... ARM has an instruction which zeros out an implementation defined amount of memory...

How can ARM ever hope to become the new-x86 with things like that? It's pretty rare a programmer wants a randomly sized bit of memory zeroed...

[dmitrygr]

Nope, the writers are just wrong. It is not a random value, and it is not arbitrary

"DC ZVA" always zeroes exactly one data cache line. That is the size. And you can easily get that size from an appropriate userspace-readable register. See for yourself: https://developer.arm.com/docs/ddi0595/h/aarch64-system-inst... and https://developer.arm.com/docs/ddi0595/h/aarch64-system-regi...

You are not expected to use it anyways. Your libc is, in its implementation of memset(), and it will properly query and use it.

Not only that, but since ARMv8.6 this instr, AND the reg you can read to get its size are both trappable by hypervisors (using HFGITR_EL2 and HFGRTR_EL2 fine-grained-trap regs respectively). See https://developer.arm.com/docs/ddi0595/h/aarch64-system-regi... and https://developer.arm.com/docs/ddi0595/h/aarch64-system-regi...

[londons_explore]

Looks like this instruction can't even be trapped to emulate a different behaviour. So that means if you design code to run on one arm CPU, you couldn't run it on another even with special kernel support to emulate the behaviour of the original CPU.