[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v7 09/12] xen: add runtime parameter access support to hypfs

On 14/04/2020 10:50, Jan Beulich wrote:
On 14.04.2020 11:45, Julien Grall wrote:

On 14/04/2020 10:31, Jan Beulich wrote:
On 14.04.2020 11:29, Julien Grall wrote:
On 03/04/2020 16:31, Jürgen Groß wrote:
On 03.04.20 16:51, Jan Beulich wrote:
On 02.04.2020 17:46, Juergen Gross wrote:
- fine tune some parameter initializations (Jan Beulich)
- call custom_runtime_set_var() after updating the value
- modify alignment in Arm linker script to 4 (Jan Beulich)

I didn't ask for this to be unilaterally 4 - I don't think this
would work on Arm64, seeing that there are pointers inside the
struct. This wants to be pointer size, i.e. 4 for Arm32 but 8
for Arm64.

We don't allow unaligned access on Arm32, so if your structure happen to have a 
64-bit value in it then you will get a crash at runtime.

For safety, it should neither be POINTER_ALIGN or 4, but 8.
This is going to make your linker more robust.

Would you mind explaining to me why POINTER_ALIGN would be wrong
when the most strictly aligned field in a structure is a pointer?
Both are valid with one difference though. If tomorrow someone send
a patch to add a 64-bit in the structure, what are the chance one
won't notice the alignment change? It is quite high.

Hmm, adjustments altering structure alignment that affect linker
script correctness should imo always be accompanied by checking
what the linker scripts has for the specific structure.

I agree with this, however this is theory. In practice, a contributor may not have noticed it and the reviewer may have overlooked it. So I prefer to make my life easier if the trade off is limited.

If you align the section to 8, then you make your code more robust
at the expense of possibly adding an extra 4-bytes in your binary.

Well, you're the maintainer for Arm, so you've got to judge. I'd
view things the other way around.
For me, review and maintenance are burden that needs to be decreased and not increased.

Yes, it's less likely for even
larger alignment requirements to get introduced, but why not be
careful about these too and, say, align everything to PAGE_SIZE?
IOW - where do you draw the line in a non-arbitrary way?

Most of decisions are arbitrary, some are more than other (e.g style).

We are down to the cost of alignment vs cost of maintenance/review longer term.

ldr/str on arm32 will request the address to be aligned to the size accessed. This will at most be 8. So by switching to 8, you remove most of the common unalignment fault.

You could use an higher alignment (such as PAGE_SIZE), but such structures are pretty limited and mostly used by the hardware. So the chance is the alignment will be correct from scratch.


Julien Grall



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.