|
xen-devel
Re: [Xen-devel] understanding __linear_l2_table and friends
> > 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
|
|
|
Home