[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®.