RE: [Xen-devel] Question about: [LINUX] Various fixes for mmapping I/Oand foreign memory pages.

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel