Re: [Xen-devel] [PATCH 4/5] xen: introduce XEN_GUEST_HANDLE_PARAM

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 6 Aug 2012, Jan Beulich wrote:
> >>> On 06.08.12 at 17:47, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Mon, 2012-08-06 at 16:43 +0100, Jan Beulich wrote:
> >> >>> On 06.08.12 at 16:12, Stefano Stabellini 
> >> >>> <stefano.stabellini@xxxxxxxxxxxxx> 
> > wrote:
> >> > Note: this change does not make any difference on x86 and ia64.
> >> > 
> >> > 
> >> > XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers
> >> > stored in memory from guest pointers as hypercall parameters.
> >> 
> >> I have to admit that really dislike this, to a large part because of
> >> the follow up patch that clutters the corresponding function
> >> declarations even further. Plus I see no mechanism to convert
> >> between the two, yet I can't see how - long term at least - you
> >> could get away without such conversion.
> >> 
> >> Is it really a well thought through and settled upon decision to
> >> make guest handles 64 bits wide even on 32-bit ARM? After all,
> >> both x86 and PPC got away without doing so
> > 
> > Well, on x86 we have the compat XLAT layer, which is a pretty complex
> > piece of code, so "got away without" is a bit strong...
> 
> Hmm, yes, that's a valid correction.
> 
> > We'd really
> > rather not have to have a non-trivial compat layer on arm too by having
> > the struct layouts be the same on 32/64.
> 
> And paying a penalty like this in the 32-bit half (if what is likely
> to remain the much bigger portion for the next couple of years
> can validly be called "half") is worth it? The more that the compat
> layer is now reasonably mature (and should hence be easily
> re-usable for ARM)?

What penalty? The only penalty is the wasted space in the structs in
memory.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel