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

Re: [Xen-devel] [PATCH 21/21] xen: more substitutions



>>> On 05.10.12 at 12:38, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> @@ -4202,7 +4205,8 @@ static int handle_iomem_range(unsigned long s, unsigned 
> long e, void *p)
>          ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT;
>          ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT;
>          ent.type = E820_RESERVED;
> -        buffer = guest_handle_cast(ctxt->map.buffer, e820entry_t);
> +        buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t);
> +        buffer = guest_handle_from_param(buffer_t, e820entry_t);

So why is this needed in the first place? I suppose it's related
to guest_handle_cast() returning a _HANDLE_PARAM(), but
what's the reason for that?

Nor would I expect __copy_to_guest_offset() to by unable to
deal with one? I.e., can't the infrastructure be made capable
of dealing with both, so pointless conversions can be avoided?

Or if not, is there really a point in making these changes on the
x86 side (they're benign there, and hence only reduce
readability)?

Jan


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


 


Rackspace

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