This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [patch] "frame number" size in hypercall ABI

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

Hollis Blanchard
IBM Linux Technology Center

Xen-devel mailing list