| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home