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

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
interface.

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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