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

Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in xen/guest_access.h

Hi Jan,

On 07/04/2020 09:14, Jan Beulich wrote:
On 04.04.2020 15:10, Julien Grall wrote:
From: Julien Grall <jgrall@xxxxxxxxxx>

Most of the helpers to access guest memory are implemented the same way
on Arm and x86. The only differences are:
     - guest_handle_{from, to}_param(): while on x86 XEN_GUEST_HANDLE()
       and XEN_GUEST_HANDLE_PARAM() are the same, they are not on Arm. It
       is still fine to use the Arm implementation on x86.
     - __clear_guest_offset(): Interestingly the prototype does not match
       between the x86 and Arm. However, the Arm one is bogus. So the x86
       implementation can be used.
     - guest_handle{,_subrange}_okay(): They are validly differing
       because Arm is only supporting auto-translated guest and therefore
       handles are always valid.

While I'm fine in principle with such consolidation, I'm afraid I
really need to ask for some historical background to be added
here. It may very well be that there's a reason for the separation
(likely to be found in the removed ia64 or ppc ports), which may
then provide a hint at why future ports may want to have these
separated. If such reasons exist, I'd prefer to avoid the back and
forth between headers. What we could do in such a case is borrow
Linux'es asm-generic/ concept, and move the "typical"
implementation there. (And of course if there were no noticable
reasons for the split, the change as it is would be fine in
general; saying so without having looked at the details of it,

Looking at the history, ia64 and ppc used to include a common header called xen/xencomm.h from asm/guest_access.h.

This has now disappeared with the removal of the two ports.

Regarding future arch, the fact arm and x86 gives me some confidence we are unlikely going to get a new ABI for an arch. Do you see any reason to?


Julien Grall



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