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 19 Apr 2006, at 20:30, Hollis Blanchard wrote:

xen_pfn_t? Definitely won't conflict with anyone, and I prefer 'pfn' to
'frameno' as it's more consistent with other names we have in the

Well technically the PFN list is actually a list of MFNs, right? I think
both PFNs and MFNs are passed across this interface... would you want
separate types for those?

Ah, well I came up with a reasonably consistent naming scheme some time ago. It is commented in one of the interface header files I believe, and here it is again:
 MFN: machine frame number (real host machine address)
GPFN: guest pseudo-physical frame number (the illusory contiguous phys addr space) GMFN: guest machine frame number (this is the special one -- it's ==GPFN for an auto-translated guest, and ==MFN for normal paravirtualised guests). It represents what the guest *thinks* are MFNs. PFN: a catch-all for any kind of frame number. 'Physical' here can mean guest-physical, machine-physical or guest-machine-physical.

So, for us, 'pfn' is kind of a polymorphic name. What you are thinking of as 'pfn' we usually call 'gpfn'. This is just the most convenient way the naming turned out when I was looking to apply a consistent naming scheme across the hypervisor and its interfaces with least changes. :-)

Attached is the updated patch, with typos fixed and a couple other
corrections. I've also added the type to arch-x86_64.h and arch-ia64.h,
so I think the patch is ready to be applied.

What about the Linux kernel -- shouldn't that be changed too? At least
where it handles arrays of longs passed to memory_op()?

In theory yes. I've been trying to limit myself to changes that I
absolutely need. A typical ppc64 system has 32-bit userland, 64-bit
kernel, 64-bit hypervisor, so practically speaking the kernel doesn't
need to change.

An interface change must be consistently applied. I'd rather have a bigger self-consistent patch than a small one that nibbles at the issue it is trying to solve.

 -- Keir

Xen-devel mailing list