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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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