dom0 auto-translate mmap()

dom0 auto-translate mmap()

[Hollis Blanchard]

Hi, as I'm porting the PPC patches to the current Linux tree, I noticed
this code in privcmd.c:
        
        static int privcmd_mmap(struct file * file, struct vm_area_struct * vma)
        {
        	/* Unsupported for auto-translate guests. */
        	if (xen_feature(XENFEAT_auto_translated_physmap))
        		return -ENOSYS;
        
        	... allow mmap to succeed ...
        }

All addresses provided to Xen by an autotranslate guest are guest
physical addresses, which Xen then translates to machine: (domid, gpfn)
-> (mfn). The problem is that dom0 actually needs to address memory
outside of its own domain allocation, but how can you distinguish a gpfn
from an mfn in this case?

PowerPC runs all domains, including dom0, in "autotranslate mode", and
so we have a workaround for this problem. When we know we're trying to
map machine addresses (which is what the builder tools do), we simply
set the high bit in "pfn" before passing it down to Xen. Xen then knows
it's a machine address.

This limits autotranslate domains to 32 + 12 - 1 = 43 bits of address
space, which I think is reasonable, especially since most "64-bit"
processors don't use many more bits than that anyways...



The net is that I would like to remove the above test. I wonder why it
was added in the first place? Somebody has a privileged autotranslate
domain and mistakenly tried to run the domain building tools?

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: dom0 auto-translate mmap()

[Keir Fraser]

On 11/6/07 17:42, "Hollis Blanchard" <hollisb@us.ibm.com> wrote:

> The net is that I would like to remove the above test. I wonder why it
> was added in the first place? Somebody has a privileged autotranslate
> domain and mistakenly tried to run the domain building tools?

Interesting. How does this work for ia64 currently? I think ia64 always runs
in auto-translate mode.

 -- Keir

Re: dom0 auto-translate mmap()

[Keir Fraser]

On 11/6/07 17:51, "Keir Fraser" <keir@xensource.com> wrote:

>> The net is that I would like to remove the above test. I wonder why it
>> was added in the first place? Somebody has a privileged autotranslate
>> domain and mistakenly tried to run the domain building tools?
> 
> Interesting. How does this work for ia64 currently? I think ia64 always runs
> in auto-translate mode.

Oh, I see they have their own mmap function. Yes, I think the test can
safely be removed.

 -- Keir

Re: dom0 auto-translate mmap()

[Hollis Blanchard]

On Mon, 2007-06-11 at 17:57 +0100, Keir Fraser wrote:
> 
> 
> On 11/6/07 17:51, "Keir Fraser" <keir@xensource.com> wrote:
> 
> >> The net is that I would like to remove the above test. I wonder why it
> >> was added in the first place? Somebody has a privileged autotranslate
> >> domain and mistakenly tried to run the domain building tools?
> > 
> > Interesting. How does this work for ia64 currently? I think ia64 always runs
> > in auto-translate mode.
> 
> Oh, I see they have their own mmap function. Yes, I think the test can
> safely be removed.

Hmm, the ia64 privcmd_mmap() is certainly interesting. It is another
approach to the same problem: they explicitly pre-register some of the
gpfn space to the appropriate mfn space.

Long-term, that's probably a better approach, since it only hijacks gpfn
space as needed, rather than halving the physical address space. For the
moment though, it also looks like a fair amount of more code... :)

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [XenPPC] dom0 auto-translate mmap()

[Jimi Xenidis]

BTW: there was a quick discussion on this before:
   http://lists.xensource.com/archives/html/xen-devel/2006-11/ 
msg00672.html

IIRC, We we continued "faking it out" until we got the ability to  
mmap'ing arbitrary pages.
Now that we fixed the ability to properly address "remote" memory,  
this should be easy enough.
-JX

On Jun 11, 2007, at 12:42 PM, Hollis Blanchard wrote:

> Hi, as I'm porting the PPC patches to the current Linux tree, I  
> noticed
> this code in privcmd.c:
>
>         static int privcmd_mmap(struct file * file, struct  
> vm_area_struct * vma)
>         {
>         	/* Unsupported for auto-translate guests. */
>         	if (xen_feature(XENFEAT_auto_translated_physmap))
>         		return -ENOSYS;
>
>         	... allow mmap to succeed ...
>         }
>
> All addresses provided to Xen by an autotranslate guest are guest
> physical addresses, which Xen then translates to machine: (domid,  
> gpfn)
> -> (mfn). The problem is that dom0 actually needs to address memory
> outside of its own domain allocation, but how can you distinguish a  
> gpfn
> from an mfn in this case?
>
> PowerPC runs all domains, including dom0, in "autotranslate mode", and
> so we have a workaround for this problem. When we know we're trying to
> map machine addresses (which is what the builder tools do), we simply
> set the high bit in "pfn" before passing it down to Xen. Xen then  
> knows
> it's a machine address.
>
> This limits autotranslate domains to 32 + 12 - 1 = 43 bits of address
> space, which I think is reasonable, especially since most "64-bit"
> processors don't use many more bits than that anyways...
>
>
>
> The net is that I would like to remove the above test. I wonder why it
> was added in the first place? Somebody has a privileged autotranslate
> domain and mistakenly tried to run the domain building tools?
>
> -- 
> Hollis Blanchard
> IBM Linux Technology Center
>
>
> _______________________________________________
> Xen-ppc-devel mailing list
> Xen-ppc-devel@lists.xensource.com
> http://lists.xensource.com/xen-ppc-devel