On Thu, 2006-04-20 at 17:18 +0100, Keir Fraser wrote:
> On 20 Apr 2006, at 17:09, Hollis Blanchard wrote:
>
> > So are you saying you want the patch to include Linux kernel changes?
> > But not Xen changes (e.g. shadow.h) other than right at the interface?
>
> Yes, at least where Linux is handling arrays that will get passed to a
> hypercall or the array could end up the wrong size! Of course it really
> doesn't matter for singleton values so they can safely be left as-is.
>
> The same goes for Xen too, but I believe the arrays are only handled in
> the very hypercall functions that receive them. For example, many
> functions in common/memory.c will need to read/write values to from a
> xen_pfn_t, but these singleton values can then be passed around inside
> Xen as longs.
But those single values can't be passed around as longs in other areas,
such as libxc. In libxc there is usually a path of xc_get_pfn_list()
-> ... -> xc_map_foreign_page() (or whatever), and I need to make sure
that the PFNs don't get truncated to 32 bits anywhere along that path.
So I don't want to limit this patch to just *arrays* of PFNs. That means
it would have to encompass all "frame numbers" in the Xen interface,
including dom0_ops, memory_ops, start_info, shared_info... Is that a
logical split for you?
Are you waiting for this patch to be finalized before applying the
GET/SET_HANDLE patch?
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home