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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 7 Aug 2012, Jan Beulich wrote:
> >>> On 07.08.12 at 14:35, Stefano Stabellini 
> >>> <stefano.stabellini@xxxxxxxxxxxxx>
> wrote:
> > On Tue, 7 Aug 2012, Jan Beulich wrote:
> >> >>> On 06.08.12 at 18:02, Stefano Stabellini 
> >> >>> <stefano.stabellini@xxxxxxxxxxxxx>
> >> wrote:
> >> > 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.
> >> 
> >> No - the caller has to zero-initialize those extra 32 bits, and the
> >> hypervisor has to check for them to be zero (the latter may be
> >> implicit in the 64-bit one, but certainly needs to be explicit on the
> >> 32-bit side).
> > 
> > You are saying that on a 32 bit hypervisor we should check that the
> > padding is zero? Why should we care about the value of the padding?
> 
> Because otherwise the same 32-bit guest kernel's behavior on
> 32- and 64-bit hypervisor may unexpectedly differ. And even if
> you didn't care to do the check, the guest would still be required
> to put zeros there in order to run on a 64-bit hypervisor. (And
> of course this costs you cache and TLB bandwidth. See how
> x86-64 just recently got the ILP32 model [aka x32] added for
> this very reason.)

Considering that no MMU hypercalls are required on ARM and that none of
the grant table and event channel ops on the hot path have any guest
handles, I think we are going to be fine.

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