Mailing List Archive

>From: Jimi Xenidis
>Sent: 2006Äê11ÔÂ14ÈÕ 4:50
>
>in changeset: 12392:e1f3af226a8e8cb32de079b283cdcac718d3e076
>you say:
> "auto-translate guests can use remap_pfn_range() rather than
> direct_remap_pfn_range()."
>
>And code says:
> kfraser 12392: /* Unsupported for auto-translate guests. */
> kfraser 12392: if
>(xen_feature(XENFEAT_auto_translated_physmap))
> kfraser 12392: return -ENOSYS;
>
>Is there a privcmd that "auto-translate guests" can use or are you
>expecting someone to fill this functionality in?
>
>-JX

The first description is reflected within direct_remap_pfn_range:
{
if (xen_feature(XENFEAT_auto_translated_physmap))
return remap_pfn_range(vma, address, mfn, size, prot);
...

The 2nd code copy does make sense to auto-translate guest,
since auto-translate guest has to allocate its real pfn bound to
foreign domain's mfn. In that case, there's no need for such
special protection about holes inside.

However, my rough feeling is, map_foreign_page may not work
for x86 auto-translate guest now since there's no logic to setup
pfn<->mfn mapping. But current interface does leave space for
other architectures to override with their own. Example is ia64,
which overrides privcmd_mmap and direct_remap_pfn_range.
You may be interested since it also operate on auto-translate
mode.

Correct me if I don't take it right. :-)

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel