Port-xen archive

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

Re: [patch] M2P/P2M abstraction

Jean-Yves Migeon wrote:
> Christoph Egger wrote:
>> Jean-Yves Migeon wrote:
>>> Hi list,
>>> M2P and P2M mechanisms are rather MD than MI. AFAIK, for Xen, the
>>> xpmap_phys_to_machine_mapping/machine_to_phys is x86 specific.
>>> This small patch [1] makes use of abstraction macros for the M2P
>>> translation, so that Xen drivers do not use M2P/P2M arrays directly.
>>> Compile tested against XEN{2,3}_DOM{0,U}, and their PAE version. Please
>>> review.
>>> [1] http://www.netbsd.org/~jym/p2m.diff
>> The changes in the patch are mechanical. The diff on itself is ok for
>> me, but if you intend to introduce an MI API, then it needs to have
>> an unique namespace prefix.
> Suggestions are open. Something like 'xpmap'?

'xpmap' is not nice to type and not easy to remember.

What about

xen_pfn2mfn_map(pfn, mfn)

Implementation can be this:

#define xen_mfn2pfn(mfn) (machine_to_phys_mapping[(mfn)])
#define xen_pfn2mfn(pfn) (xpmap_phys_to_machine_mapping[(pfn)])
#define xen_pfn2mfn_map(pfn, mfn) (xen_pfn2mfn(pfn) = (mfn))
#define xen_pfn2mfn_unmap(pfn) (xen_pfn2mfn(pfn) = 0)

For the last one, I'm not sure if zero is the right value to mark an
invalid entry.

> I use them to track down the different code paths requiring translation
> from/to MFNs.
> The current names are those found in XenSource's Linux.

I know. Linux and abstraction are mutually exclusive. :)


Home | Main Index | Thread Index | Old Index