Re: [Xen-devel] Xeno Linux never pins L1 tables ?

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> > 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