Re: [Xen-devel] PAE, Elf headers, and Extended CR3 registers

[Randy Thelen <rthelen@xxxxxxxxxx>]

Keir Fraser wrote:

> [extended-cr3] was only needed to provide backward compatibility  
> for old
> guests that do not grok the extended cr3 format. None of those  
> older guests
> support this new Elf notes format (since the new format is much  
> newer than
> the introduction of extended-cr3 format). So if the guest uses Elf  
> notes
> then it is implicit that it understands extended cr3 format and  
> there is no
> need to state that explicitly.
Understand the extended cr3 format?  Do you mean hardware or  
virtualized cr3?
I'm confused.  Did I draw an incorrect assumption from this code  
(from xc_linux_build.c):
    /* First allocate page for page dir. */
    ppt_alloc = (vpt_start - dsi_v_start) >> PAGE_SHIFT;

    if ( pae_mode == PAEKERN_extended_cr3 )
    {
        ctxt->vm_assist |= (1UL << VMASST_TYPE_pae_extended_cr3);
    }
    else if ( page_array[ppt_alloc] > 0xfffff )
    {
        nmfn = xc_make_page_below_4G(xc_handle, dom, page_array 
[ppt_alloc]);
        /* Error handling removed */
        page_array[ppt_alloc] = nmfn;
    }

In the case of PAEKERN_extended_cr3, a 64 bit cr3 register is assumed  
and thus any page in the memory space (up to 64GB) is a valid page  
directory.  Whereas with a x86-class processor, only a 32 bit CR3  
register is present and so the page directory has to be in the low 4GB.
??  What am I missing?

I'm trying to get FreeBSD 6.0 in 32 bit mode + Xen 3.0 support  
running in on a 32 bit Xen w/ PAE and I just want to understand the  
cr3 register from Xen's point of view.
-- Randy

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