|
|
|
|
|
|
|
|
|
|
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.
> 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)?
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?
Current state is that xen itself comes up fine, the domain 0 builder
completes, but the xenlinux kernel is killed via domain_crash() very
early, before the first message appears on the screen, and I'm trying
to figure what is going on ...
Gerd
--
#define printk(args...) fprintf(stderr, ## args)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|