| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Xeno Linux never pins L1 tables ?
> > Xen catches the faults on writing to pagetables. In more recent versions
> > of
> > Xen, it traps each write and emulates it. In older versions, it will
> > unhook
> > the pagetable temporarily, allowing the guest to write directly to it.
>
> Does that need a vm_assist() call to enable writable page tables? or is
> this the default? Yes I am using an older version of Xen (Xen 3.0).
A vm_assist() is required to enable "writeable pagetables", yes.
> There's an explicit pagetable update API for guests to batch changes to
>
> > pagetables rather than using trap-and-emulate if there is a large group
> > of changes to be made.
>
> I plan to use HYPERVISOR_mmu_update() call to batch my pte changes. So
> going by Keir's reply I guess I have to use this hypercall in my set_pte()
> function that modifies a pte entry - even though I didn't explicitly issue
> an L1_PIN request to the hypervisor.
That sounds about right; pagetables are pinned recursively - you can't pin an
L2 table without implicitly pinning all its children. This is because the
validity / safety of an L2 table's contents depends implicitly on the
contents of the L1 as well. Pinning validates the pagetable as conforming to
the constraints required by Xen; it wouldn't make sense to validate an L2
table without checking that the ptes its children referenced also conformed
to these constraints. So that's the rationale for this behaviour.
> What's troubling me is that linux-2.6.18-xen writes to the pte entry
> directly by dereferencing a ptep! I think I am missing something here.
You're allowed to do that, once you've activated writeable pagetable mode.
Your Xen 3.0 release will then do something like the following:
1) verify that you're writing to an L1 pagetable, and unhook from its parent
L2 table
2) make the page writeable so that the write can succeed
The guest will run for a bit and may now issue further writes without trapping
into Xen. If the guest tries to access a virtual memory address within the
range covered by that L1 table then it'll cause a fault during the
translation process. This will trap back into Xen, which will:
3) notice that the fault was caused by a pagetable unhooking of the writeable
pagetable code
4) the page is made read only again, and all the changes in that pagetable are
revalidated at once.
5) the L1 page is hooked back into the pagetable structure
6) the faulting instruction in the guest is retried; it should now succeed
This process makes it possible for a guest to get the illusion of writing
directly to the pagetables but also to benefit from batching of update
operations when many changes to the pagetables are being made.
More recent versions of Xen provide the same interface to the guest, but
implement a trap-and-emulate approach: Xen traps the write faults and
individually validates each attempt to update the pagetables before updating
them on behalf of the guest. This is faster in the common case of the guest
making a small number of updates. The guest can use the explicit batching
interface when it wants to update a larger range.
I hope this helps clarify things a bit.
If you don't mind me asking, why are you using such an old version of Xen?
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home