Re: [Xen-devel] understanding __linear_l2_table and friends

[Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>]

> > There are three possible soloutions for L3 accesses : 
> >  * wrap them in map_domain_mem. This will be very slow
> >  * burn 2MB of VA space in an L2 to map the L3
> >  * insist on every pagetable having a reserved L1 in which we can steal
> > a 4KB slot
> 
> According to Keir linear tables are used for L1 access only anyway, so
> this probably isn't an issue.   Beside that I'd probably go with (1).
> l3 in PAE mode is just 4 entries, so access to them very likely is rare,
> thus I'd rather take small the map/unmap performance hit than trying to
> implement complicated things like (3) which could have unexpected side
> effects all over the place in the paging code.

That'll be OK to get paravirt mode working, but the shadow modes do
do a fair number of accesses to L2(L3) pages via linear mappings.

Scheme #1 will do for starters, though. Scheme #2 is easy too, but
we have to be careful how much lowmem we burn.
 
> > In the first instance, it probably makes sense to get PAE working using
> > hypercalls everywhere, and then debug the emulation path, and finally
> > enable full writeable pagetables.
> 
> I'm not that far yet ...
> 
> How does the console output of domain 0 work?  Is it passed to xen via
> hypercall?  Or does domain 0 manage it itself (very early in boot)?

It goes via a hypercall. To get early printk, just hack the
following into the obvious place in kernel/printk.c after vscnprintf:

HYPERVISOR_console_io(CONSOLEIO_write,  sizeof(printk_buf), printk_buf);

> How far goes the boot of the xenolinux kernel in domain 0 with the
> initial pagetable setup created by xen's dom0 builder?  I think
> I should see some kernel messages from linux before it actually
> touches the page tables?

With the above hack, yes.

Cheers,
Ian

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