| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Machine and Physical address
> I have posted this same message earlier during the day through the
> gmane.com.emulators.xen.devel newsgroup but I don't think that the message
> made it through. I am now emailing directly to the mailing list. Sorry if
> my posting appears twice.
>
> I am trying to undestand how the memory address translation works on Xen.
> My question is the following. Do the page table entries of a guest OS contain
> physical page frame numbers OR real-world machine frame numbers ?
For performance reasons, domains normally run in 'direct mode',
whereby the page tables the guest manipulates are the page tables
accessed by the MMU hardware. Hence the PTEs contain machine
frame numbers. Xen ensures that a guest can only create PTEs that
point to pages it owns, and ensures that it can never create a
writeable mapping to a page table page (otherwise it could
violate the previous rule). [Actually, its more complicated than
that as Xen 2.0 allows domains to write to their page table pages
directly, but ensure the page is validated before the hardware
can access it.]
In addition to 'direct mode', there is 'shadow mode' where Xen
maintains a cache of shadow pagetables that are used by the
hardware. Entries in the shadow table are created on-demand and
kept syncronized with the guest's page tables.
Arbitrary mapping functions can be implemented between the guest
and shadow pagetables. For example, we use shadow mode to learn
when pages get dirtied to enable us to implement 'live
migration'. You could also use shadow mode to give domains the
illusion that they have a contiguous physical memory map starting
at address 0 rather than the arbitrary sparse map they really
have.
The disadvantage of operating in shadow mode is that you pay a
performance cost of having to keep the pagtables synchronised,
and also there's a memory overhead of having two sets of
pagetables (if the cache isn't big enough, performance is
terrible). The memory overhead can actually be quite large if
you've got a dumb application like Apache 1.3.
> I have tried the following little experiment.
>
> 1.) Within a guest OS (domain 1), I read the value of a page table entry
> (pte_val). The value of 'pte_val>>12' would then correspond to either a
> machine
> frame number or physical frame number.
The PTE memory location will hold the machine frame
number. However, the pte_val macro will return you the
'psuedo-physical' frame number as the MFN gets converted into a
PFN by looking it up in the machine_to_phys table.
> 2.) Then from within domain0 I issued the hypervisor call HYPERVISOR_dom0_op
> with option DOM0_GETMEMLIST. If I am correct, that hypervisor call returns a
> list of real-world machine frame numbers being allocated to my guest OS.
Yep, you'll get a list of MFNs.
> 3.) From the list I got in step 2 above, I search for 'pte_val>>12' but I
> do not
> get any matching entry. However if I search for
> phys_to_machine_mapping[pte_val>>12] then I do get a matching entry.
Yep.
> So from the above experiment it seems that pte_val contains physical page
> frame
> numbers. However, if that is the case, I do not see how xen translates each
> virtual memory reference within the guest OS into the correct
> address.
See the definition of pte_val in include/asm-xen/page.h
> I have a second question not directly related to the above. I am trying to
> trace
> through XEN and I don't know where all the printk will be displayed. Printk
> within the guest OS kernels are all logged within their respective
> /var/log/messages files, but what about the printk within XEN ?
If you've configured a serial line they go there -- very useful
for debugging. Otherwise, you can collect them with 'xm dmesg'
but that won't do you much good if you've crashed ;-)
> I read that XEN shares the console of domain0. My grub.conf file is configure
> with:
>
> kernel /xen.gz dom0_mem=100000
> module /vmlinuz-2.4.26-xen0 root=/dev/hda7 ro console=tty1
>
> But the printk from within XEN do not seem to appear on tty1.
Nope -- Xen can't feed things back to dom0. You could configure
dom0 to use console=xencons and let all of the messages go out
through Xen rather that letting dom0 take over the VGA. I'd
certainly advise getting a serial line set up if you're going to
be debugging.
Cheers,
Ian
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home